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

what's up ladies and gentlemen it's Ryan here and today I want to talk about why you should not use websockets unless you absolutely need to so here I have a demo of a progress bar receiving data from the back end in real time and updating the UI 10 updates per second and it's working great and this is all without using polling and without using web sockets so everything I'm talking about is backing agnostic it doesn't matter which back-end you're using whether that's node.js golang rust C C plus plus Java python it could be whatever doesn't really matter so when it comes to creating real-time-ish applications there's a few different use cases that come to mind like a chat application such as Instagram Snapchat or Whatsapp if it's a multiplayer game that obviously needs a lot of interactivity if it's a collaborative user experience like Google Docs where multiple people can edit the same document in real time or if you want to show the user incremental progress updates kind of like I just showed you in the demo preview nicely so when it comes to creating real-time applications the first question is how well the first place I would look is TCP and UDP because those are the low-level protocols for network communication those are a step below HTTP but those are not supported in the browser so we're not going to talk about those so ultimately we'll have to choose between the HTTP protocol or the websocket protocol so the first thing we can try is polling because it's the simplest solution pretty quick to implement but the downside of that is it creates very high latency because there's that round trip from the client to the server and back for every single request and that latency adds up so usually the next thing we reach for is web sockets it gives you fast bi-directional communication which makes it pretty much suitable for most use cases but on the flip side websockets does increase the code and infrastructure complexity of your system particularly because it makes your system stateful where you have to keep track of the sessions for each user that's connected so here's an example of the most Bare Bones infrastructure you can have where your browser connects directly to the API server and occasionally your API server makes database requests and that's pretty much it but in real life your system is more likely going to look like this so typically the browser would connect to a load balancer which would evenly distribute traffic among replicas of your API server typically you have an orchestration layer like kubernetes that would be responsible for creating these replicas so in our simple architecture we could store all of our websocket sessions and memory and that really wouldn't be a problem because sessions are sort of temporary anyway but that same approach does not work once we scale out horizontally because we have multiple buckets of memory right each replica has their own memory and we don't want to bog down our database with all of those reads and writes so we'd use redis as our single source of Truth for storing user sessions so there's another approach we can take called server-side events it's very simple it builds on top of HTTP and by default it's stateless but one of the caveats to using server-side events is that it is one directional so the communication only goes from the server to the client it's very fast but only in One Direction of course if we need to send data from the client so the server we can always use a post request for that so if you want to implement server-side events on your back end regardless of the language here's how you have to set up your response so let's get into the nitty-gritty of all of this and see what the code looks like so here I'm handling the get request to slash progress so everything I'm about to show you is happening inside of the request Handler so the first thing we have to do is send the header so we need to set the content type to Text slash event stream then we have to disable the cache because we don't want this endpoint to be cached and so here's how that would look and go with a context writer header set so once we've done that for the content type and the cache then we have to flush the writer and this is going to immediately send this to the client so we don't want to close the request we just want to update the header and then send that to the client immediately so what I have here is a loop that's going to send events to the body of the request using this format so we have one line with the ID this is an integer that's incrementing we have the event which is the name for that event and then we have some data associated with that event and then we have to add a new line after that as well and so this is how the implementation looks for that everything's happening inside of a loop and just to sort of simulate the passage of time I have a sleep happening on every iteration of the loop so in my case every one tenth of a second is going to go through each iteration of the loop so here coming back to the example this is what it looks like we can see the request here and we can see see ID type and data so here I loaded up that API endpoint in Chrome in the browser and we can see it's incrementally appending each event to the bottom of that response until the very end where it's done and then it just closes that request so this goes to show that it really is just a simple HTTP request that's incrementally sending data through the response and so once everything is said and done then it just sends the last event called done along with some data so this is what it looks like on the front end we have our Event Source equals new event Source pass in the URL to our endpoint then we say eventsource dot add event listener with the name of our event parse the event.data and there you go and you could do this over and over for every individual event so that you want to handle then at some point in the future when you're ready to clean up and close that Event Source you just say eventsource dot close so you can see that it's actually pretty simple to implement server-side events so at the end of the day you should use the simplest solution that will solve your problem and if that's not enough then upgrade to the next solution polling is the simplest solution you could Implement that in five minutes but the reason the rights are going to be pretty slow because there's latency for every HT ATP request so for server-side events it's more of an intermediate solution and since you have one long-lived HTTP request all that data can be piped from the server to the client really quickly but then to send data from the clients to the server you're going to need to use post requests which aren't that fast and of course at the end if all that fails then you can use websockets it's fast it's bi-directional it's great it's just that there are certain technical challenges you run into as you scale horizontally you might need to tweak your load balancer to use sticky sessions or you might need to add some single data store like redis to persist your sessions so as usual it's Orion here if you like the video please like And subscribe support a little YouTuber like myself and thank you for watching

Channel: Code With Ryan

Views: 163,167

Keywords:

Id: 6QnTNKOJk5A

Length: 6min 45sec (405 seconds)

Published: Sun Dec 18 2022