Don't Use Websockets (Until You Try This…)

[@codewithryan]

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

[@DonDregon]

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!

[@cedricopese]

@@DonDregon Clear, simple and smart. Thanks

[@IsaacShoebottom]

O poor

[@dyto2287]

@@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.

[@OzzyTheGiant]

@@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.

[@JohnZakaria]

At first I thought clickbait but then the video was 100% legit quality content.

[@dabbopabblo]

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

[@AbdullahKhan-x3k1c]

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

[@bastian9945]

I just watched this on 1.5x and the Quality and Structure of the Information was superb, keep it that way

[@CameronFlint07]

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!

[@lavenir9907]

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.

[@ighsight]

Underrated comment. Which of these approaches is best for push notifications?

[@lavenir9907]

@@ighsight idiomatic way for push notifications - Push API

[@funnycompilations8314]

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.

[@ozzyfromspace]

This was a superb exposition of Server-sent events, thanks Ryan!

[@whamer100]

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

[@danielgilleland8611]

Kudos for talking about this little-known/little-used feature for us web developers!

[@kevintanudjaja7597]

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

[@cirosobral]

Man, what a great voice! Just found your channel and I'm listening just because it sounds incredible. Keep up with the good job.

[@robkom]

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.

[@codewithryan]

Good catch 😂

[@bossgd100]

maybe you should create your youtube channel also lol

[@petarsworld]

@@codewithryan TPC = TCP grammar mistake at the beginning :)

[@foreveryoung6108]

This is the best introdution for Websockets, awesome.

[@GrzesiuG44]

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.

[@jaagup]

Chrome I think limits only http 1.1 requests to 6. With http 2 and 3 it can do more.

[@mrmagnetic927]

Outstanding job. TIL about SSE and this video definitely explained the process very well. PROUD of YOU

[@verified_tinker1818]

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.

[@nubunto]

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 😅

[@OtakujiOfficial]

It's pretty simple and for me it's indeed the best solution for notification system and can also be used for realtime chats. Excellent video!

[@BrainInteractive]

This is so cool, I did not know this even existed in HTTP until now, thanks!

[@JorneDeSmedt]

Well, I'm mailing this video to my work email. I needed this months ago.

[@everythinggoes850]

Underrated communical channel. In fact, most apps should adopt SSE instead of websockets.

[@julienr8114]

why ? What is the avantage of SSE vs Websockets ?

[@keremardicli4013]

It is very costly for the server compared to ws, and it is one way only.

[@isaacvr]

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.

[@mdmarcaassport]

Im very happy with ws. Thr only good reason to not be happy is with horizontale scale. But it has to be a way to handle it

[@Cyber_Lanka]

awesome video Ryan. I wasn't aware of SSE until this.

[@cellocarlos]

You are awesome! I've heard about SSE but never knew how actually do that. Thank you, bro!

[@josemata8865]

Nothing better than learn something new with a cool voice in the background

[@lokeshstufs]

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.

[@Thegamecheats]

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.

[@Ma1ne2]

I had NO idea this exists, this is such a cool mechanism, thank you very much for sharing!

[@Fs3i]

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.

[@paulgaiduk709]

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!

[@Gandalf_Le_Dev]

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

[@intervalia]

Great video. I didn't know about server-side events yet. Thanks for the info.

[@LegitoTV]

Hi! I just found your channel via the GTA 3 code review. Great stuff sir thank you for sharing your knowledge.

[@jochemmm]

I'm getting into Go and microservices, so I really enjoy your content. Very well explained and enjoyable to watch.

[@HollywoodCameraWork]

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.

[@essamal-mansouri2689]

You can solve the same problem with JWT and still be stateless

[@diadetediotedio6918]

​@@essamal-mansouri2689 In reality, you can't have the "same problem" solved. When we talk about a trusted channel we are talking about the TLS process, not the internal authentication to use your server, and the TLS is pretty "heavy" in relative terms for any realtime application.

[@cod3a]

Dude, you have a gift for explaining IT concepts in a very simple way. love it

[@arson5304]

legendary content, never heard of server side http events before

[@srh80]

Its fine if all clients receive all events. For most use cases like a chat app you need a stateful connection per client. Either u maintain that state or a framework does. There are tons of frameworks that maintain connection state and provide you just an endpoint. So yea, just use websockets and scale with a cloud provider solution when your app moons.

[@mikeeomega]

Honestly, great video... I often forget that SSE exist until I dream a solution with SSE

[@avidcaster]

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.

[@avithedev]

Love being an early subscriber to a channel that I know will blow

[@maciejkag2735]

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!!!

[@dabbopabblo]

Woah this is so fitting for the live stream event system Im implementing for time based user reactions and vote/polling

[@gaiusify]

Hey Ryan thanks for this video! Do you answer questions over emails?

[@williamgomez6226]

Very good speech. Very well spoken!

[@twomtyler]

Great explanations and summary of the different options. Thanks a bunch

[@v0xl]

Rocket (rust web framework) has awesome support for SSE!

[@jwbonnett]

I feel you need to let people know of the security implications of using SSE as it sends all events to everyone, whereas websockets you can send to the individual. It could be sensitive data, intended for a specific user.

[@ksomeone1]

this is why I picked websockets over sse

[@MAK_007]

Excellent video. I love your videos. Thanks

[@mattiasfagerlund]

I was about to use Websockets, but this worked perfectly instead - thanks!

[@hanswoast7]

That was a great overview. Thanks Ryan!

[@seanweber4252]

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!

[@elkindvasquez5715]

Thank U so much, you literaly saved me a lot of work

[@sam421kc]

Im so glad I found this. thank you.

[@fz_0283]

you nailed it bro, completely awesome🎉

[@elementotriplo4966]

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!

[@yankluf]

Woow! Excellent video!! It resolved all my doubts and muuch more! Thanks!! 😁😁

[@tesla1772]

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

[@giuliopimenoff]

RabbitMq for a more reliable approach imo

Dude, great voice! You should be on Radio!!

[@OverMartinez]

Nice video and nice approach! Do you think if there is a similar implementation using nodejs instead of Go?

[@simonfarre4907]

Stream like communication is probably a better definition than a realtime, though realtime is the used term.

[@justadude8716]

This is a very informative video, short and to the point!

[@DejayClayton]

Nice overview. For completeness, you should also cover long-polling, which was the popular solution before WebSocket (singular, not plural).

[@keyonlewis7574]

KZbinr: when he say statefulness me: flutter is that you

[@markoffk]

There is also improved version of polling called "long polling"

[@yss64]

Very insightful video. Thanks!

[@ooslik]

This was a really helpful video man. Thanks!

[@alexdith9024]

just won my sub..awesome content and really explainative.. thanks!

[@frontend_ko]

okay understood, clear explanation and clear voice, thanks!

[@tashima42]

Awesome video, keep it up Ryan, learned a lot from you.

[@BraisonsCrece]

Really interesting! Thanks for sharing. I love the way you teach. New subscriber! 👌👏🎉

[@RK-on4si]

Great video, very informative. Your insights were incredibly valuable.

[@altaccount648]

I feel like bro's neck must hurt after looking to the side for the entire video like that

[@n0kodoko143]

Glad I found this!! Awesome stuff

[@akmzahidulislam2764]

Great video, boss! Keep it up!

[@leuhenry8031]

your voice sounds awesome and I like it.

[@JMCV2]

I've used gRPC with HTTP2 (and Envoy proxy) for bidirectional communication

[@alnahian2003]

bro u just got a new sub 🎉

[@priyankverma7434]

I really needed this Thanks a lot for a fab video tutorial.

[@Gaivs]

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 😅

[@ForChiddlers]

Nice. Now I would really like to know how Websockets work internally

[@neozes]

Good stuff mate! Thanks!

[@ericisawesome476]

This was informative, thank you

[@amirp3487]

Well explained, thanks Ryan!

[@codelinx]

Such good info and tutorials

[@Fingiorstyle]

Oh my gosh, great tutorial!

[@codecaine]

Excellent content

[@Felipe-53]

Awesome video!

[@novailoveyou]

Really nice videos bro thank you!

[@rzr1191]

SSE might also be more battery-efficient depending on your usage

[@mikopiko]

Very well explained

[@GottZ]

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

[@Pscribbled]

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.

[@rofgar]

Another option would to use JWT/JWS for the session when using websockets.

[@mariumbegum7325]

fantastic video!

[@njw1233]

This is how chat gpt responses in multiple chunks to a single request

[@m4rt_]

Great video.

[@carlkarl]

bro the way of explaination and your voice is so cool , thanks for the help for my project

[@lawrencedoliveiro9104]

Interesting that MDN warns that there is a limit of 6 SSE connections per domain on common browsers (unless you are using HTTP/2), while I can see no mention of a limit for WebSockets.

[@azizutkuozdemir]

Super valueable .thanks