Don't Use Websockets (Until You Try This…)
HTML-код
- Опубликовано: 17 дек 2022
- Using websockets increases the code and infrastructure complexity of your app, especially as you scale horizontally. Depending on your needs, you may be able to use Server Sent Events (SSE) instead. Server Sent Events is more efficient than polling, but simple to implement on both the backend and frontend.
Note: Depending on your specific project, using SSE you may still result into the same horizontal scaling challenges as WS (e.g. sticky sessions/central sessions store). It entirely depends on what kind of feature you’re implementing and how you're moving data around. But I’ve found that SSE provides a simpler base to implement realtime functionality if the client is mostly just receiving updates.
Someone made a highly scaled MMO game with SSE: news.ycombinator.com/item?id=30312897
^^^ That thread also includes some interesting discussions around SSE.
Here's a performance comparison between SSE and WS (spoiler alert: both are pretty much the same): www.timeplus.com/post/websocket-vs-sse
Using SSE you are limited to 4 tabs on the client side plus the client-to-server comm is -usually- made through HTTP requests. SSE are meant to be a better way to solve push notifications, on any other real-time use-case, WS will do a way better job.
Cheers!
@@DonDregon Clear, simple and smart. Thanks
O poor
@@DonDregon You are like 8 years outdated about this. This limitation is only for HTTP/1. If you use HTTP/2 you can have thousands of SSE connections concurrently on same browser. If you use firewall proxy like CloudFlare that exposes your HTTP/1 backend as HTTP/2 you already get that and this connection limit is not relevant for you.
As for replacing WS with SSE - it can be done but useful for stuff like when you receive more messages from server than you send. Because to do a mutation or a change on server you would make a REST call and then server would broadcast that change via SSE connections. And it is way more scaleable since you can scale and architecture client side requests endpoints as any REST API.
On additional note, if you use WS on phone while connected to mobile data, it will drain phone battery faster than SSE because of the nature of connection. To maintain sending stream on WS phone keeps another antenna feature turned on for sending data which drains battery quick. So SSE is usually preferred for mobile app if it can fit your needs.
@@DonDregon Why would anyone even need more than 4 tabs for the same content? I fail to see a use case where this is even necessary, but yes SSE is meant for receiving notifications or data updates from the server.
I swear to god EVERYthing you talk about is soo god damn relevant to what Im working on at any given time. I am so glad I discovered this channel
SignalR covers all the scenarios you mentioned. By default it will try to use web sockets and gracefully fall back to the other transport types. However you can configure it to use a specific transport type. Just remember, with WS and SSE, you may have to explicitly configure routers
just found your channel (by searching for the differences between Rust and Go) and I must say that your channel is totally underrated. There are many channels with 500k+ subs out there that don't even match the quality this channel has. I also like the simplicity of the channel. I go walking quite often and I can listen to your videos on my headphones because I can understand most of the things just from listening to your voice. Keep up the good work and please make more videos like this where you go through some "slides" and explain/compare things.
Today I learned! I didn’t know there was an intermediate solution to server-side push between polling and websockets. Great presentation of the options too. Thanks!
I'm getting into Go and microservices, so I really enjoy your content. Very well explained and enjoyable to watch.
Hello, thanks for mentioning this technology. This is a good way to get simple one-way events like "server to client", but in most cases, when an application moves to an event-based messaging model, SocketIO or WebRTC is used. SocketIO has a wonderful fallback mechanism for older browsers that uses pooling. At the same time, WebRTC allows you to set up a fast exchange model + additional sugar for working with video, audio and text streams.
Underrated comment. Which of these approaches is best for push notifications?
@@ighsight idiomatic way for push notifications - Push API
damn Ryan, you are just plain awesome! I came to your channel by just searching YT for videos on websockets and because your were so high in the search result list I thought you have some big production with videos on every possible topic. But no! I see you just recently started the channel and all the videos you made sound super interesting! No bs, only interesting topics, only interesting tech. I promis you I'm gonna watch them all. good luck with the channel!
Hey man I really liked the vid. It's clear that you've put some thought into what makes a clear, concise instructional video and I plan on checking out your other videos now!
wow ive never heard of SSE before, i was just about to start making a project that eas going to need server -> client communication and didn't want to deal with th3 complexity of websockets; this is perfect! great video as well
Man, what a great voice! Just found your channel and I'm listening just because it sounds incredible. Keep up with the good job.
Outstanding job. TIL about SSE and this video definitely explained the process very well. PROUD of YOU
You are awesome! I've heard about SSE but never knew how actually do that. Thank you, bro!
I just watched this on 1.5x and the Quality and Structure of the Information was superb, keep it that way
A very good video, good theory with diagrams and a technical example. All of this in under 10 minutes ! Very impressed and I learned a lot, thanks
Interesting I do think that websockets are going to be a lot cleaner in the code and require less data to be sent between, you are going to run into similar issues with both Server-Side events and Websockets when scaling, at least with websockets its better documented and understood. But I do like how you pointed out some differences and I think its good to understand and know as many options as possible.
What I would be interested in is a way to communicate between a server and client using no javascript, something like long-polling. This would be great for people who use TOR and aren't using javascript because of privacy and security concerns. I have seen some interesting solutions to this but so far nothing very clean.
Would be huge for privacy and security people if someone found a solution to this. I imagine an instant chat application that ran securely through TOR with no javascript would be pretty huge.
Hi! I just found your channel via the GTA 3 code review. Great stuff sir thank you for sharing your knowledge.
Kudos for talking about this little-known/little-used feature for us web developers!
There's nothing actually wrong with the statefulness of websockets. Most load balancers can do this already and maintain a sticky session for you. When you start streaming with SSE, you've still got state to manage for reconnects (offsets etc). Similar with seasons beyond even basic complexity. There's a lot of tools like Ably, Pusher and others that manage all of this state for you, handling the scale out. A websocket is full TCP connection with a bit of extra framing. You can send binary data without having to move to HTTP/2 (which is still less supported that it should be)
you can also apply a queue for handling indirect connections, you can always reconnect with the queue and the history will be secure between the server instances
websockets are also easy to reopen so even if it's stateless it won't be a big issue
Thanks! I learned something new today.
What's wrong with it is websockets are overkill for certain applications which I feel he did a good enough overview of the reasons why. Adding even more complexity doesn't really change this.
Dude, you have a gift for explaining IT concepts in a very simple way. love it
Great video! You refer to SSE as "server-side events" but it seems it's officially referred to as "server-sent events". Knowing the difference between short vs long polling might also be useful.
Good catch 😂
maybe you should create your youtube channel also lol
@@codewithryan TPC = TCP grammar mistake at the beginning :)
awesome video Ryan. I wasn't aware of SSE until this.
Woah this is so fitting for the live stream event system Im implementing for time based user reactions and vote/polling
I had NO idea this exists, this is such a cool mechanism, thank you very much for sharing!
This is a very informative video, short and to the point!
Great video. I didn't know about server-side events yet.
Thanks for the info.
Awesome video, keep it up Ryan, learned a lot from you.
Underrated communical channel. In fact, most apps should adopt SSE instead of websockets.
why ? What is the avantage of SSE vs Websockets ?
It is very costly for the server compared to ws, and it is one way only.
I don't see it very practical. Is like having two arrays, one for age and other for name to represent a list of users, instead of using a class. With SSE you have one-direction stream + post (two event sources). With websockets you have a single source of events. Simpler, cleaner and bidirectional.
That was a great overview. Thanks Ryan!
Nice overview. For completeness, you should also cover long-polling, which was the popular solution before WebSocket (singular, not plural).
This is the best introdution for Websockets, awesome.
Great video, very informative. Your insights were incredibly valuable.
Good explanation. I love when people explain why NOT to use something instead of just assuming. Only non standard thing you're using here is "GO" not sure if this is necessary or not.
This is so cool, I did not know this even existed in HTTP until now, thanks!
legendary content, never heard of server side http events before
Great explanations and summary of the different options. Thanks a bunch
Hey Ryan thanks for this video! Do you answer questions over emails?
Well, I'm mailing this video to my work email.
I needed this months ago.
At first I thought clickbait but then the video was 100% legit quality content.
If nothing chaged, both pooling and SSE suffer from being included in the count of connections to same host. With browsers limiting their count to 6 by default this was a serious reason to avoid both of them and using websockets instead.
Chrome I think limits only http 1.1 requests to 6. With http 2 and 3 it can do more.
doesn't this move the state of the open connection from an explicit data store to the HTTP server's thread pool?
Super valueable .thanks
Really interesting! Thanks for sharing. I love the way you teach. New subscriber! 👌👏🎉
Well explained, thanks Ryan!
Nice video and nice approach!
Do you think if there is a similar implementation using nodejs instead of Go?
Great video, boss! Keep it up!
This was a really helpful video man. Thanks!
If I remember, Google Sheets is implemented using Long Request, no-polling strategy. That's insane considering they can do real-time collaboration at that time without websocket
Very insightful video. Thanks!
Woow! Excellent video!! It resolved all my doubts and muuch more! Thanks!! 😁😁
Good stuff mate! Thanks!
Glad I found this!! Awesome stuff
Love being an early subscriber to a channel that I know will blow
damn this would really help with my current project! im trying to avoid websockets and i dont need client->server communication so thanks a lot!!!
I have to point out the elephant in the room: the Phoenix framework. Since it (well, the language and runtime) is based on the actor model, it's fantastic at scaling horizontally, and the statefuless of WebSockets (which it uses extensively) make some things a lot easier; not to mention more efficient, because you don't need to send/receive a whole HTTP request, only the relevant data.
I love phoenix and elixir, but what I don’t like is having to be tied up to the BEAM. I’m also honestly not very good at it too, so that might play a big role 😅
The statefulness of websockets is a feature, not a bug. It allows you to do rigorous authentication once at the front-end API, creating a trusted channel where messages passed to back-end services side-load authentication information that cannot be user-provided, so they don't have to re-do authentication. This creates a single place where authentication happens, and not every single API endpoint on every single back-end node. Eventually something goes wrong if every endpoint is responsible for authentication, and the API becomes porous.
Really nice videos bro thank you!
Very good speech. Very well spoken!
okay understood, clear explanation and clear voice, thanks!
I really needed this
Thanks a lot for a fab video tutorial.
from the graph at end of video looks like websocket is the best way for fast read/write? if so why we not using it for push notification and rather use SSE in most cases?
I wish I'd seen this video earlier, it would probably have made a previous project of mine easier, especially to get a prototype going... WebSockets was pretty difficult to get going for a non-web-dev, both for frontend and backend... Oh well, now I have a new tool in my belt if I ever have to do something similar again 😅
Excellent! Thanks very much 👍
Thank you, Ryan,
This excellent video has given me a lot to think about - I need to implement real-time, bi-directional and encrypted communication between a client and server app and I am planning to create the production backend using Golang (currently Python) - the existing client app uses Java and it connects to the server via AMQP, but I am able to edit the clients connection method as needed...
I currently have things working (unencrypted) on my LAN using AMQP - but I want the server to sit on the internet and allow distributed clients to connect over the web...
I was thinking that WebSockets would be the way to go but having seen this video I am now not so sure... I am a bit of a noob so please forgive my ignorance - having watched your vid, I did a search and saw that I can actually encrypt AMQP messages between the client and server so I am now thinking 'why not do this over the internet' rather than swapping out the transport method for a more 'web focused' tech, which was what I thought I would have to do...
Can you see any probs with using encrypted AMQP messages over the web, or do you think that switching out the connection method from AMQP to SSE/Websockets would still be a good idea?
The messages between the client and server will contain 'alpha/numeric' data and I need the transport between endpoints to be encrypted and take place as fast as possible...
I realise I may be being a bit cheeky here, in asking you this, but I like your channel and the way you explain things - so if you don't give a direct answer to this question here, then it may give you some ideas for a future vid, which could be helpful...
Anyways, thanks again for what you do - I hope to see your channel really grow in 2023 as I think you deserve it!
Hey Mark, I’m not familiar with AMPQ, but I’ll gladly chat with you about this and go through some ideas. DM me on twitter @ryancodez
There are browser based limitation with SSE. Specially when u use TLS 1.2 or less. It limits the number of parallel connection. The user can't have more than 5 tabs open per application.
just won my sub..awesome content and really explainative.. thanks!
I want to try this out!
bro u just got a new sub 🎉
Your voice is great for movies. Excellent videos.
Client has 10 screens.
If user triggers any changes they see the response.
Server keeps enum for 10 screens. If any user info is changed indirectly,server updates the enum list accordingly.
On every request the enums are sent in the header.
Client sees a change of enums from last value. Then it makes a request for updated data.
Client is one request behind the server. Any requests will update everything if in focus.
Not sure if I know what I’m talking about (jr dev) but wouldn’t elixir work in the cases you mention to whip up multiple processes?
Honestly, great video... I often forget that SSE exist until I dream a solution with SSE
Great video. In the example of a chat app, what if there are multiple chat rooms? Can server side events “subscribe” to one channel like we sockets?
thanks for sharing!
This was informative, thank you
Thanks for the video.
I am working on a big data project. I need to show around 2,00,000 dataset, result http time out error and mysql dumped the query.
I was thinking to use websocket events to send prices of chunk data to browser asynchronously. Let me know if we can use that in there
Oh my gosh, great tutorial!
How does SSE solve the horizontal scaling problem? The server still needs to keep track of what client to send the data to right?
Such good info and tutorials
Server side events, i didn't know it worked, when i heard about it i thought it was just long pooling. But in long pooling if i'm not mistaken each time the server answers the client needs to immediately send another request, with server server event the client just stays connect, that's cool, thank you!
Most of the time if bi directional communication is read heavy we can get away with SSE and a post method. But horizontal scaling will still remain an issue we'll need something like redis pub sub to gossip events between servers
RabbitMq for a more reliable approach imo
Is there any security down sides of Server Side Events approach?
work of art
Would this solution also bind the browser client to a specific server instance that has the connection open? If so, wouldn't it cause trouble for autoscaling?
does it switch api servers during the communication though? i don't see how it's any less stateful than a websocket. you have a single long ass communication where the server knows the state thereof. you may authenticate with a user, you may not
i definitely see how it's simpler though. super easy to implement and it should cover a good portion of the use cases.
what excites me more than either of these is webrtc. webrtc is capable of setting up peer to peer connections between clients. it doesn't necessarily transfer just media streams. it can make up for the absence of UDP regarding multiplayer gaming on browsers with a specialized framework
Dude, great voice! You should be on Radio!!
Great explanation! One question, how do we scale server sent events? How do we ensure that no message gets lost if a client closes the connection? Can we apply the same logic of scaling web sockets to sse as well?
SSE protocol has a header to soecify the last processed event, it can be specified on case the connection is lost and server can backfill
It's server-sent events, not server side events. See, for example, section 9.2 of the whatwg html standard (current version of the living standard as of this comment).
And despite using SSE, I'm not sure if I agree with your advantages. The main advantage of using EventSource over WebSocket is, at least to me, that EventSource does its own connection management. If the connection drops because of a transport-layer issue (e.g. client lsot internet temporarily because mobile networks), EventSource reconnects automatically. It doesn't reconnect always (e.g. if the sends 204, or, iirc, in some implementations if the server sends 5xx status codes), but for most "normal" failures it handles its own connection management, which is neat! Especailly, if you're using a library for SSE on server, then it can happen entirely automatically.
Also, every implementation of a LB for WS I've seen has had the sessions "stick" to one API server anyway (by virtue of keeping the TCP connection alive), because otherweise things go crazy, but if you have any resources for an implementation that *doesn't*, I'd be very interested.
Also, the "slow writes" might not even neccessarily be true if you're keep-aliving a connection the browser can reuse, or if you're using HTTP2, writes would be just as fast. The bigger problem I'd see is that they're not attached to a websocket session. If you're (for example) developing a game, it's utterly helpful if you have the paradigm of "one socket per user", it reduces the mental load to know which specific instance has sent which message, etc. (On the other hand, even with http2, I might be worried about the overhead of very small messages)
On the other hand, it can be an advantager. e.g. for an application like discord it *doesn't* matter which specific client has deleted a message in a chatroom, just that they're authenticated.
Q) is it right way secure split user communication with different " WS channels " ? is there some authentication for verification owner ?
Excellent content
Awesome video!
on frontside, if the connection drop (for eg: user switch the wifi) will the EventSource re-connect automatically? or we need to handle this case ourself? and how?
Thank you sir! I was extremely didactic.
Rocket (rust web framework) has awesome support for SSE!
Hey, so weird question. would it be possible when sending serverside request, to ask the server to treat the client as a server where the server may receive data from the client in a semi continues fashion?
It is correct to use Websocket to create a audio transmition application?
fantastic video!
Thanks so much very helpful😀
Amazing video!
I've used gRPC with HTTP2 (and Envoy proxy) for bidirectional communication
Very well explained