Server-Sent Events Crash Course

server-sent events can be used to transmit data from the server to the client in a unidirectional manner that proved to be useful for use cases such as live feed logging and other use cases as well in this video / crash course I want to discuss the following and guys you guys start seeing some chapters on YouTube where you can jump into the interesting part of the video there's code there's so much good stuff here pros and cons and discount on this content so feel free to jump through the video all right so I'm gonna discuss HTTP because it's very important server sent events or built on top of HTTP at least partially right so we're gonna discuss how HTTP work 1 0 1 1 and how this is critical for long left connection talk about WebSockets a little bit very briefly because they you will be left into a state where you don't know which one to pick and I wanted to help kind of guide you there I can't make the decision for you unfortunately but I can't you can watch my WebSockets video to learn more but it's really tough decision right I'm gonna talk about it a little bit so that's very important server sent events obviously the meat-and-potato about this thing how this works really it's not really rocket science is very simple then I'm gonna go jump into the code so you can jump into the directly the code I'm gonna do is Nord GS and and and this thing is so simple to build guys because it's the trick is to know how to unlock it essentially right so I'm gonna build a noches Express server I'm gonna consume it from the browser window using raw event source that's the API in the browser and then for now I'm gonna talk of the pros and cons of what they see is e which is server sentiment because guess what nothing is perfect how about we jump into a guys so how the first thing I'm gonna discuss is HTTP 1 0 back in the 90s way back 1995 we invented HTTP protocol and we try to be smart and we said ok in order to send a get request I'm gonna establish a TCP connection three-way handshake all that jazz between the client and the server and I'm gonna connect to port 80 because this gdb protocol have the TCP open send the get request wait and then once they get the result there is a server sends the result I'm gonna close the connection okay that's the design that was always in the case since I should tip 1 0 and then foreign send another request open another connection send a get request for the image and then wait for the result and then close the connection and do it all over all over again that was very bad we quickly fix that in HTTP 1 1 and the reason is because TCP opening and close is is very very expensive because we talked about the three-way handshake check out this video right here but in a nutshell that's very we were worrying about the memory a coupe I buy the TCP so we don't want to leave it open why we forgot the performance so we got a hit right we fix that problem which DB one one very quickly we said ok let's leave the connection open and there is what I keep a live hitter by the folders DB 1 1 if you don't send that it is by default open so now open that connection and then send the first good request receive a respond send our get request receive the response send a get request and finally you want to close if you want optionally right and that's it that's how it should be one one works and based on that having a running TCP connection that we can use all over and over and over again became very very efficient right and now well socket came in to lunch ok I want to reuse the WebSocket connection so that I can send information from the server to the client client-server bi-directional we talked about that right so to do WebSocket we do the same thing we open up a connection and we send the first request which is a get one one HTTP one one upgrade and then we receive a response from the server saying ok I support WebSocket let's switch protocol but that is completely revamping the protocol it's not no longer HTTP right now the client can send information to the server the server can send information to the client this I can send some more information to the client the client can send some more information the server can send there is no order it's bi-directional that's what sockets essentially in a nutshell right and here is like we're we we kind of hooked into the underlying TCP connection it's a little bit more than that the WebSocket protocol we it's it's there are some overhead attached to it compared to server side of an server sent events I'm gonna talk about that but in a nutshell it is we're using this in a bi-directional manage different than raw TCP it's it's a protocol by itself it's a well-defined protocol okay so what is server sent events guys so server sent events guys is the ability from the server I don't really need by direction I don't want the client to communicate with the server and server communal all this I want only the server I know that connection will always be unidirectional the server will send me stuff so what do you do same thing you open a connection has to be HTTP one one right because keep alive cause persistent connection and the first thing you send as a client is not a bug raid not anything what you have to send text event stream that is the trigger that tells the server that you want to establish by a unidirectional server sent events channel so the server will receive then will say ok and will behave server and you can build this right now is here's where you need to respond you need to respond with content that dual does this the following the header the content type is text slash event stream Jason will won't work normal textual work has to be event stream so the client actually understand that you understand that it needs this the second thing it has to be transfer encoding chunk because as well we're playing on on a long polling game here where we don't know how long is this response so we say okay let's chunk this up and we don't know when is the last packet so otherwise we will have sent the content content length header right just like okay this is a 700 bytes but we don't know so we say chunks and then what what happened after that is the server keeps sending more chunks keep saying me more chunks keep that's it that's what server sent events not rocket science at all and we're gonna build one guys so that's essentially the idea and then finally once you're done you can close the connection either the server can close the connection or the client can close the connection there are a little bit tricky things when it comes to HTTP 1 1 especially in a browser since you have like maximum 6 connections per domain or this weird hack that the browser's have with HTTP 1 1 we don't have this problem was to issue DB 2 because we have a one beautiful TCP connection we have streams what are the use cases what can I use this for well you can use it for live feeds especially YouTube videos right I'm gonna saying YouTube use that like streaming write a few streaming content from the server you know that you don't want anything else right I'm not sending it I just want to open the connection and then everything is gonna come from the server so live feed and blogging live blogs and conferences for example that's a perfect use case wait I don't want to use heavy WebSocket protocol where it has like these additional headers and stuff I want just like these lightweight packets sent by the server to the client so that's live feed life it is very good use case and other problems like hey I wanna I I want to send a job to the server but I want a server to update me on the progress of this job let's say this is an asynchronous long job executing if insourcing or servers and events is very good use case like this you can show a progress the server can send you their progress so oh 20 percent complete I'm 30 percent complete I'm 40 percent complete yeah is it easy to implement I'm gonna say no because you have to really build it to really build it I don't know if that makes sense or not logging yeah the same thing okay you sent one request and you you want to stream the logs on the server or unistream what is happening on the backend so yeah use cases finally good time so coding guys so what we're gonna build here we're gonna build a raw server-side server sent events client server using node.js from scratch and then from the client we're gonna start consume it how about we jump into it all right guys let's jump into it and build our application so I'm gonna go ahead and open a brand new folder I'm going to my JavaScript playground because I have all my projects right here go check the repo and it'll get a server sent events right and then just like that open this puppy up and we're gonna do it create my alright so the first thing we're gonna do is we're gonna create an index to j/s file our beautiful index.js file and then we're gonna do the usual stuff Const app equal express require Express write and then app dot yet we'll just create a very simple server here that literally just responds with responder send hello this is just to just to get the ball rolling okay so I'm gonna listen on port 8080 console dot log listening on 8080 that's a very simple that's the simplest thing we can build right so go ahead and initialize NPM and all that jazz NPM in need to - why NPM install that's it we're just gonna install Express I think I have to say NPM install Express room alright and BM installed Express installed let's go in and run no Jess all right let's check this thing out I'm gonna go ahead and do localhost:8080 we're gonna say hello so I was saying where does the server-sent events that you talked about well let's get to it guys so the first thing we're gonna do here is we said that to to unlock server-sent events at the back end we need a get request a special get request I can use the route but I'm not gonna because I want these to be different so I'm gonna do a stream endpoint right I'm gonna do this so this will be the response and what we need to do here is really just set the header that is content type and what is it called it's called text event stream that's the trick guys that's the most important thing once we have that what we need to do next is literally just use the method right we shouldn't use and we shouldn't use send this is HTTP specific we need to use right so that we are constantly writing to the same TCP connection packets right so that's the trick here okay and we can and and we can write the following text right it has to be that's the trick here it has to be data and then Colin and then space and then you put your garbage here number so it's like okay plus hello very simple stuff here okay that's it obviously where are the streams this is one event if you want to send to another event just do it twice okay and we're gonna do a timer and all that jazz in a minute no but let's do this I'm gonna put a debug point here and refresh this puppy right now just like that I am going to the client refresh this puppy this will work obviously but now I'm going to and developer tools go to console clear this up and then I'm gonna do let SSC which is the server-side event equal a new event source this is this is a built-in thing in the browser and if I do HTTP localhost 8080 slash treem I will send that special get request that effect that sending that nuke reading then you will send a get request with the event stream as content type guys right just like that we should see as we said or look at that we got we got a debugger I'm not gonna press continue yet I am going to hook the event how do i how could event just like we do with WebSocket on message equal console dot log right basically what this does it like this is giving it a function I give it console dot look so to print everything that we receive from the server yeah now we wait go back and we release the Kraken and just like that there you go so here's what I did I forgot this this is another part of the protocol you have to add two new lines to signal that this is an an event okay so data has to be like that there's a space after it and then you have to do that right so now we have received it look at that we receive two because I have two fresh there twice look at that where's the data is the data hello this is awesome let me refresh the whole thing again clear the whole thing again and then do it well here why are the message we got a request release the Kraken and get just like that we got the message look at that alright let's place things a little bit guys spice things up and I'm gonna do a function here called send it takes the response and it's a set timeout and literally calls itself and every second what does it do it does exactly that and then that's great just a variable here let zero hello let's do text here just for beauty purposes and that's it we do that and then here we call send and obviously we pass the response how are we try this what will do what what will this do guys this will basically forever we'll keep sending Nessa so I don't need to debug anymore right so we're gonna call this once and then every second we're gonna write an event right obviously you needed a condition where you stop and kill the connection by doing it or is not connection necessarily but stop the events the series of them by doing rest don't end but look at that I keep streaming and this is another feature in the event source library it even if you destroy the back end connection that client will keep connecting will keep connecting and that's pretty neat let's refresh this again so I can show you right before we show that that look at that connected immediately I can receive okay hello 0 0 0 okay I did a mistake I forgot to increment this thing alright don't bloom I should be better and now look look at this guy's I killed the server that client just resumed like there is no tomorrow that's a pretty nice feature unlike it's almost like a it's a stateless protocol it's almost stateless Lee designed I'm Michel socket if you kill the WebSocket connection tough luck man you have to reestablish it yourself right so that that's so guys look at that that's that's pretty neat feature alright so we talked about that so the trick here is is this the text event and that chunk encoding right because we get we're going to receive keep receiving content on this thing right and these are the events stream you can you can and visualize it on the dev side of things awesome guys so that's it that's basically server-sent events in a nutshell how about we jump back into the slides and I'm gonna provide the source code for you guys obviously and yeah how about we jump into it guys all right guys so we did server-sent events we built some source um server we built a client and then it is a very simple design architecture right however is it perfect no it's not perfect so how about we jump into the pros and cons of this thing the pros first it is lightweight and I have to give it that I even why shark that stuff I'm gonna make it another video about why sharking server said sent event it's very lightweight the packets are so small because there are no headers guys unlike the WebSocket WebSockets have its own headers its own protocol its own thing that you they have to send it with everything and it's even have this concept of a logical connection and a logical close and logical open so there is an over head with WebSockets that you don't have a server sent events so that might be a good thing if you want to lightweight thing obviously some cases where you don't want an over TCP with UDP specifically quick oh my god if you can get this server sent events over quick or HTTP 3 that should be the kind of the winning lottery thing because it's a very thin lightweight protocol okay it is compatible by HTTP HTTP obviously because worsening that requests so it's HTTP compatible HTTP and it's also gonna buy which is TP 2 this is not true with WebSocket by the way guys when we sockets we did something with a db2 we had to invent a new RFC to solve this problem with WebSockets sockets what what it does if I establish a connection between more the kind and the server we first of all we style the CCB connection htv-2 and then we create streams for every request so get request gets a new stream and like a channel inside that TCP connection what sockets by design it was designed to basically hijack the entire TCP connection which is extremely wasteful in case of HTTP 2 right so they are coming up with a new protocol I'm not sure if it's it's up or not but we want essentially to to hijack one stream 4 4 4 4 WebSockets server sent events don't have this problem you don't have this problem because by design you're gonna hijack one stream and you will just inject everything in that two stream and will just work right so that's that one that's why people say that you can see a big warning on Mozilla don't use server sent events to be one because you will get quickly you will run out of number of connection because they you have a limited number of connections so usually HTTP - so you can just use a stream and all multiple streams right so that's much much much much better so it's compatible should be to http right so that's a that's another advantage over you guard if you want to learn more about HTTP HTTP in general and htv-2 it's specific check out the playlist right here so you can go over there at this screen and then scream I'm gonna link to the playlist to learn more about all the stuff firewall friendly why because it's TB HDD beep right I'm talking about encrypt unencrypted stuff right because if it's if it's encrypted firewalls cannot do anything about it but if it's unencrypted it is far off friendly just like WebSockets because hey I'm connected through port 80 please allow me it's a good request as a normal get request and once you establish the TCP connection everything is just dandy right Kohn's what's bad about this proxying is a little bit tricky not as hard as WebSocket WebSocket we just gave up and you said you know what layer 4 scene all the way with with server-sent events we had we can do layer seven proxying we can terminate the TLS and even recent continually sending the events but it is you need to specifically send set some headers and let the connection be alive already by default HTTP 1 1 & 2 is the connection is always alive but it is a little bit tricky to implement right I'm not gonna say it it's it's straightforward layer 7 is a little bit challenging exactly as we said right therefore it is the easiest obviously just stream everything into the layer 4 and just blindly address the package to the backend without looking at them but layer 7 if you will start to make sense of the packet and you look and you start decrypting you and you make decisions then you have to worry about timeouts and stuff right because okay how how far should ok can I open this connection and leave it open it because server sent events you have to keep the connection open and and if there is no data coming from the server what do you do do you do you kill the connection probably not so you have to go to the proxy again so back to the proxy is tricky and then kind of tweak the timeouts to kind of increase them right specially these are special times just just keep a life time up make it as large as possible even in idle times right because guess what the client cannot send anything so the client cannot keep the connection alive it's the responsibility of the server so if the server's not well written in a ways to kind of send pings to the client so it wakes up then you have to kind of tweak the timeouts at the client at the proxy side right whether this is a proxy or a reverse proxy okay it is it is stateful yeah yeah it is a stateful and the server side because yeah once I send a request I am I am hooked to one server right so it is it is hard to scale is not as hard as WebSockets though because with WebSockets there are two way communication with bi-directional with the uni-directional you can't design a server that just does the same thing over and over again so it is I might I might take a question mark here and says okay might be actually stateless in this case right because yeah I will just for the proxy to a server and then all this data is coming from the server to me to that connection but what happened if I kill the connection right we we saw event source just attempt to Creek connect again if we go reconnect again we're gonna go to another server yeah the state is different in this case but if you have yeah so whatever the the state at the server is gonna be reset so if you don't care and your architecture is stateless then you might get away with it you can build it in a stateless manner do you have to use server sent events depends on your use case really I mean live feed we talk about live feed specially with the UDP my god this is really good but TCP and there are still every event sent from the server need to be acknowledged by the client at the TCP transmission control layer so that's that's a cost right however WebSockets right it's most of the time if you think about it I think that's my personal opinion I think server sent event is kind of limited right because there I I cannot think of a way of a use case where it's only purely server sent events right there might be in the future I might need the client to send information in there in the process in the during the communication duration and in that case I might need to absorb it so might as well just use web socket and use bi-directional in this case right and yeah you might argue that web socket is a little bit there's an overhead to it with the HTTP there are no headers and WebSocket but there are its own protocol headers right it's not a lot but it is if you if you accumulate them they are they they are can be they can be significant right compared to the raw service sent event which is just a bunch of strengths the only thing they required us to send us this data the limited thing a little bit I didn't like that to be honest I thought this is a little bit hacky it's like why do we need to something just data string I don't know whatever there's also long polling which reminds me a lot of server sent events it's very similar very very similar almost identical to be honest we're long polling is like okay I'm gonna send her a quest but I'm gonna wait wait for the server the server will not respond back to the client until it gets an information right but the server and local in case only have one shot right because it's a wreck still at the request response kind of a thing right so a long point can be implemented at the HTTP layer it's just the server kind can just delay the response this is okay I'm not gonna respond to you just so we can we don't want to over over saturate the network right so that for the list of saturation use this for multiple events coming only when one direction you use this for multiple requests from the client and one response use this for by direction in Woo's web socket so to me I think I'm gonna always use WebSockets to be honest I'm I don't see a use case for this I might be wrong let me know in the comment section below guys if you have used it in one of your use cases I would love to hear that summary so yeah guys it was a quick course crash course on server sent events and we talked about HTTP 1-0 we talked about in a problem about that we quickly solved it as engineers and who came a bullish TP one one as a keep a live connection and persistent connection and then we said okay let's hijack that TCP connection so we can Eve's web sockets obviously we made a big mistake with that because HTTP 2 is very inefficient to hijack that TCP connection so we need WebSocket at a stream level we're still working that out and RFC forgot which RFC that I'm gonna reference it to though I even make the video about it I'm gonna reference it right here or maybe in the editing server sent events we talked about that and we did some code yayyyyy we also talked about pros and cons guys what do you think about this this technology will you are you gonna use it or you're not gonna use are you sticking to WebSockets are you sticking with normal HTTP because request response is all you need let me know and all these comments in the comment section below I'm gonna see in the next one you guys stay awesome subscribe to this channel for more back in the engineering stuff EAS software engineering all that stuff we discussed in this channels check out all the content and in this channel I'm gonna see in the next one you guys say awesome goodbye

Channel: Hussein Nasser

Views: 19,254

Rating: 4.9771428 out of 5

Keywords: hussein nasser, backend engineering, server-sent events, sse vs websockets, sse vs long polling

Id: 4HlNv1qpZFY

Length: 29min 48sec (1788 seconds)

Published: Fri Jul 17 2020