Don't Use Websockets (Until You Try This…)
Вставка
- Опубліковано 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.
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
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
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!
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!
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
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
I'm getting into Go and microservices, so I really enjoy your content. Very well explained and enjoyable to watch.
Man, what a great voice! Just found your channel and I'm listening just because it sounds incredible. Keep up with the good job.
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!
I just watched this on 1.5x and the Quality and Structure of the Information was superb, keep it that way
You are awesome! I've heard about SSE but never knew how actually do that. Thank you, bro!
Outstanding job. TIL about SSE and this video definitely explained the process very well. PROUD of YOU
Kudos for talking about this little-known/little-used feature for us web developers!
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
Hi! I just found your channel via the GTA 3 code review. Great stuff sir thank you for sharing your knowledge.
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.
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.
I had NO idea this exists, this is such a cool mechanism, thank you very much for sharing!
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.
awesome video Ryan. I wasn't aware of SSE until this.
Nice overview. For completeness, you should also cover long-polling, which was the popular solution before WebSocket (singular, not plural).
Woah this is so fitting for the live stream event system Im implementing for time based user reactions and vote/polling
Hey Ryan thanks for this video! Do you answer questions over emails?
Great explanations and summary of the different options. Thanks a bunch
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.
Great video. I didn't know about server-side events yet.
Thanks for the info.
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 :)
That was a great overview. Thanks Ryan!
Nice video and nice approach!
Do you think if there is a similar implementation using nodejs instead of Go?
Dude, you have a gift for explaining IT concepts in a very simple way. love it
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.
This is the best introdution for Websockets, awesome.
I've used gRPC with HTTP2 (and Envoy proxy) for bidirectional communication
This is so cool, I did not know this even existed in HTTP until now, thanks!
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
Great video, very informative. Your insights were incredibly valuable.
Very good speech. Very well spoken!
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 😅
Awesome video, keep it up Ryan, learned a lot from you.
legendary content, never heard of server side http events before
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
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.
You can solve the same problem with JWT and still be stateless
Well explained, thanks Ryan!
Very insightful video. Thanks!
in between polling and sse lies long-polling.
honorable mention since it was the go-to prior to ws and sse.
sse also had a hacky way to be done prior to the spec by sending tags to an
Well, I'm mailing this video to my work email.
I needed this months ago.
Good stuff mate! Thanks!
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
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.
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 😅
I really needed this
Thanks a lot for a fab video tutorial.
Love being an early subscriber to a channel that I know will blow
Really nice videos bro thank you!
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!
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
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!!!
This is a very informative video, short and to the point!
okay understood, clear explanation and clear voice, thanks!
Excellent! Thanks very much 👍
This was a really helpful video man. Thanks!
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?
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.
Really interesting! Thanks for sharing. I love the way you teach. New subscriber! 👌👏🎉
Rocket (rust web framework) has awesome support for 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?
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.
Glad I found this!! Awesome stuff
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
Super valueable .thanks
Great video, boss! Keep it up!
Such good info and tutorials
Woow! Excellent video!! It resolved all my doubts and muuch more! Thanks!! 😁😁
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
thanks for sharing!
At first I thought clickbait but then the video was 100% legit quality content.
work of art
Q) is it right way secure split user communication with different " WS channels " ? is there some authentication for verification owner ?
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?
What about the limits of SSE for non SSL hosts? Ie 9 simultaneous connections per host max
I know most sites will not be clear text but this limitation is important to know during development
This was informative, thank you
just won my sub..awesome content and really explainative.. thanks!
Awesome video!
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?
bro u just got a new sub 🎉
I’m pretty sure SSE will still hit the same issues as WS from what you were talking about. On top of that, the server side implementation for SSE seems messy and maybe not as supported as WS is and WS gives you more than SSE.
With respect to real-time multiplayer games, how they’re typically implemented is with a gameserver where the players connect to the gameserver directly. This is ok because game servers are inherently stateful and you’d design them in a way to handle large numbers of players properly if your game requires it.
I want to try this out!
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?
Another option would to use JWT/JWS for the session when using websockets.
fantastic video!
Thanks so much very helpful😀
Thank you sir! I was extremely didactic.
sse has header overhead, websocket has encode decode overhead, xhr streaming with file stream is very simple for bi directional communication and zero overhead , u need to reconnect when data length > something 10mb thats all, sse less compabilty than websocket, websocket is not allowed ie11-( windows webview still use ie7-8) best compabilty is xhr streaming
Excellent content
Oh my gosh, great tutorial!
great video!
SSE might also be more battery-efficient depending on your usage
Dude, great voice! You should be on Radio!!
Very well explained