[Front-End System Design] - Chat application

  Рет қаралды 33,501

Front-End Engineer

Front-End Engineer

Күн бұрын

Пікірлер
@PavloD9
@PavloD9 4 жыл бұрын
Thanks for your video! It is a pleasure to watch such well prepared videos. Some questions for the API part: 1) Why is it easier to load-balance SSE connection than a websocket? Technically, both are using persistent TCP connection under the hood. If connection breaks, browser reconnects to the LB (same or different node) in the same way. 2) Websockets and firewall issues - when using SSL, all three methods will look the same for the outside observer - a firewall will only see the SSL handshake and then some random encrypted data 3) Keeping a websocket connection is expensive - why is it more expensive than keeping any other TCP connection? A single websocket connection can be shared between browser tabs using a localStorage 4) Long polling connection timeouts - isn't it applicable to Websockets and HTTP/2 as well? 5) Long polling latency and traffic overhead - when using HTTP/2 connection multiplexing and keep-alive, the overhead will be close to zero, because TCP and SSL handshake will not be required (which is the most time consuming part of connection). Or am I missing something else?
@FrontEndEngineer
@FrontEndEngineer 4 жыл бұрын
Hi, Pavel. Thank you for the great questions. I'll try to answer :) 1. with a WS, as you said, you need to break the connection with a server and reestablish this. This can lead to negative side effects of handling such an event both on the client and on the server. With SSE, there is no need to re-connect to the LB instance because HTTP2 enables multiplexing, which will allow the app to receive the data from the different server node without breaking the connection with LB 2. Depends on the configuration and org filtering level. With a WS, your browser sends an upgrade header, which switches the HTTP protocol to TCP. If you org configured TCP traffic filtering, then you can have a problem. But, I should say, I am not an expert here. I was involved in solving such a problem indirectly :) 3. You're right. Excellent point. Thank you :) This is not a problem until you need to think about multiplexing and handling multiple sources. Basically, we can solve the performance issue by making a single socket connection. Still, we need to re-invent a wheel to send multi-source message data on the server, which greatly increases architecture complexity. 4. Yep, you're right :) 5. You're right, but the latency is still a problem. When you're using a mobile device, you're constantly switching between the network cells. This is called - "Retransmitting," the message is carried over the network cells, which possibly can lead to longer latency. You can't avoid headers traffic overhead, which is not a problem in the SSE case.
@geethurajasekharan1883
@geethurajasekharan1883 Ай бұрын
Thank you both!! This is exactly the kind of questions an interviewer might ask and you've given us a feel of that too! And great answers from the author!
@Vitalik186
@Vitalik186 3 күн бұрын
for number 1, I would add that the main reason why it's easier to balance SSE, is that the connection type is unidirectional - and from the server perspective - a client is stateless - so no additional logic required after a connection is broken
@kalpanagupta6166
@kalpanagupta6166 3 жыл бұрын
@Front-End Engineer Great job. I would like to suggest a few more things that are important in Web development 1. Security 2. Performance, Fatals errors and event metrics 3. SEO 4. Rate limiter
@jeffb587
@jeffb587 2 жыл бұрын
FYI everything you have under "general reqs" are actually functional reqs, and everything under "functional reqs" are actually non-functional reqs
@SincerelyLucia_
@SincerelyLucia_ 2 жыл бұрын
He made this mistake in every video lol
@chrisrey2516
@chrisrey2516 8 ай бұрын
Thanks. I thought I was going crazy but it could just be language barrier
@MidhunDarvin625
@MidhunDarvin625 4 ай бұрын
Thanks, would have made the same mistake
@KamalTesting-ct6cx
@KamalTesting-ct6cx 4 ай бұрын
Thank you for sharing such informative session with us. Totally appreciate your efforts. Keep making and sharing this wonderful session. Thanks
@ripplesr5655
@ripplesr5655 2 жыл бұрын
This channel deserves more recognition! Thank you so much!
@ayaramzy6815
@ayaramzy6815 3 жыл бұрын
First Thank you I had this question in my last interview .. He asked me about data flow in the chat itself view how I can divide the components and then ask me about data entities for chatting private or in a group so add this part please in the video .. hope this comment found by others who preparing for frontend design system
@gj677
@gj677 2 жыл бұрын
This is gold! Thank you for creating this video and sharing your thought process. You’re amazing!
@huhuanxin4178
@huhuanxin4178 4 жыл бұрын
good video man, thanks for your time and making this front end architecture/system design series videos. Learn a lot from your videos.
@FrontEndEngineer
@FrontEndEngineer 4 жыл бұрын
Thank you 🙏
@williamernesto
@williamernesto 3 жыл бұрын
Great video! This is as thorough of an explanation of FE architecture as i have seen in one of these. One thing that would help thoroughly is if you don't mind sharing your design document.
@blank001
@blank001 3 жыл бұрын
This channel is highly under rated such a good content and good explanation, keep it up man.
@anandkanu12
@anandkanu12 2 жыл бұрын
While I appreciate the effort to come up with frontend system design, I think the difference b/w Long Polling/Web Sockets/SSE is very opinionated and not generalised. Eg. SSE => not sure how it is resource efficient? client would have to send messages through different mechanism (maybe REST), and receive through SSE, which leads to inconsistent application design. Also, adaption of HTTP 2 is very limited. (Google tried pushing the first draft with Server Push, and failed, since the protocol and the transport was very buggy).
@大盗江南
@大盗江南 6 ай бұрын
Great point of view! So many talented dev out in the world
@oRiGiNaLMrInsaf
@oRiGiNaLMrInsaf 6 ай бұрын
so many information, that was useful, thank you
@BhavikGosrani
@BhavikGosrani 3 жыл бұрын
awesome content... learnt a lot for frontend system design
@gauravkesarwani1918
@gauravkesarwani1918 3 жыл бұрын
You are missing the search bar in the contact list in your component architecture. I think you should have a ContactsContainer with ContactsList and Search as two sub-components. Wdyt ?
@gururajchadaga
@gururajchadaga Жыл бұрын
having authorId and recieverId in the message will make it hard to scale for group messages. we need another entity called conversation, which will hold the name and id of the conversation. The message entity can only have the authorId, and all the members of the chat(1:1 or groups) can go into another entity called conversationUsers, which will have the userId and the conversationId. This way, scaling a 1:1 chat into group chat is just a matter of adding another row into the converstationUser table.
@karthikjoshi6386
@karthikjoshi6386 12 күн бұрын
excellent video but I have question around websockets vs SSE applications like discord are using websocket that proves it is scalable with proper configuration and handling where as applications like chatgpt are using SSE this also brings question why they are not using web sockets as their main functionality is chat any insights on this will be very helpful
@gauravkesarwani1918
@gauravkesarwani1918 3 жыл бұрын
The fetch contacts api call should be when you render the ContactList so should be one level above in the diagram
@shreyasd9103
@shreyasd9103 2 жыл бұрын
What is the reason to store attachments seperately in the data store? Is it not a part of messages?
@kanishmalviya
@kanishmalviya 2 жыл бұрын
Third column should be non-functional req. based on sub points you have written ?
@jingjiejiang8919
@jingjiejiang8919 Ай бұрын
SSE is not good for chat applicaiton, coz chatting is not a "server" driven events, it is about both ends. Websocket is the option
@NovaMenteMedia
@NovaMenteMedia Жыл бұрын
what about getting messages by contact id?
@saqomelqon1618
@saqomelqon1618 2 ай бұрын
SSE is a terrible idea for a chat app. It’s unidirectional. It’s good for things like live stock price updates pushed from server to client but not chat. Yes, scaling and managing websockets is a pain but needed in this case.
@ArshadKhan-dk5zf
@ArshadKhan-dk5zf 3 жыл бұрын
Thanks a lot for this video. I have been searching for frontend system design for chatting app. It will be great if you could share the design doc as image/xml file for quick access. Once again thank you for the system design content.🙂
@gauravkesarwani1918
@gauravkesarwani1918 3 жыл бұрын
Which collaboration tool are you using for drawing diagrams ?
@tsaregrad
@tsaregrad 3 жыл бұрын
I’ve seen many videos about designing chat applications, mostly from BE perspective though. Why no one is considering WebRTC for the task?
@bos9824
@bos9824 Жыл бұрын
its better for video
@yoshitaarora4180
@yoshitaarora4180 2 жыл бұрын
28:24 - Optimization
@keksinjo
@keksinjo 2 жыл бұрын
I don't really understand why you separate requirements to general and functional? Imho it's more common to use functional/non-functional. Functional like: users can send messages, attach media ...; non-functional: perfomance, stability, memory usage and many others.
@SanekZZZ1
@SanekZZZ1 Жыл бұрын
Unfortunately, you didn't attach this diagram to the video. ;(
@ayaramzy6815
@ayaramzy6815 3 жыл бұрын
where is the diagram link?
@ayaramzy6815
@ayaramzy6815 3 жыл бұрын
can I really prepare schemas before the interview ... It is not bad to appear as I saw the question before ??
@ZhekaMechsheryakov
@ZhekaMechsheryakov 2 жыл бұрын
You are right, better to focus on the questions and draw needed diagrams in live mode
@jlrobert
@jlrobert 3 жыл бұрын
how come the ids are "string" and not "number"? thanks for the vids!
@brianschermerhorn7294
@brianschermerhorn7294 3 жыл бұрын
If you want a unique ID - usually they have to be long enough such that an integer doesn't hold enough characters to make it so. A string however - works. Such as UUIDs.
@LytbII
@LytbII 2 жыл бұрын
What is brottle? Didn't find anything
@keksinjo
@keksinjo 2 жыл бұрын
brotli
@jhalakmaheshwari234
@jhalakmaheshwari234 3 жыл бұрын
What is brottle format?
@OleBjrnMichelsen
@OleBjrnMichelsen 3 жыл бұрын
I think he's referring to Brotli, an improved (over gzip) compression format for HTTP.
@yahwehagape
@yahwehagape 3 жыл бұрын
Unidirectional
@yahwehagape
@yahwehagape 3 жыл бұрын
Server-Sent Events
@Soileau
@Soileau 3 жыл бұрын
I love your videos, it's awesome to see these system design questions from a frontend perspective. But you gotta turn off grammarly, man. That is so distracting. I had to rewind several times because the popups distracted me over and over.
[Front-End System Design] - Typeahead Widget
36:30
Front-End Engineer
Рет қаралды 26 М.
[Front-End System Design] - Design a Poll Widget
35:04
Front-End Engineer
Рет қаралды 20 М.
Cheerleader Transformation That Left Everyone Speechless! #shorts
00:27
Fabiosa Best Lifehacks
Рет қаралды 16 МЛН
Frontend System Design Interview (Build Instagram)
21:28
theSeniorDev
Рет қаралды 15 М.
Frontend System Design Interview (Build Google Search)
18:55
theSeniorDev
Рет қаралды 8 М.
[Frontend System Design] - Deep dive into HTTP [Part 1]
23:37
Front-End Engineer
Рет қаралды 10 М.
System Design Mock Interview: Design Facebook Messenger
14:50
Exponent
Рет қаралды 278 М.
[Front-End System Design] - Typeahead component
1:01:23
Front-End Engineer
Рет қаралды 10 М.
[Front-End System Design] - Data Table Component
45:04
Front-End Engineer
Рет қаралды 16 М.
WHATSAPP System Design: Chat Messaging Systems for Interviews
25:15
Gaurav Sen
Рет қаралды 1,9 МЛН
Front End System Design Fundamentals (All In One Comprehensive Guide)
37:50
Cheerleader Transformation That Left Everyone Speechless! #shorts
00:27
Fabiosa Best Lifehacks
Рет қаралды 16 МЛН