[{"data":1,"prerenderedAt":324},["ShallowReactive",2],{"post-\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets":3,"post-link-en-external":315},{"id":4,"title":5,"body":6,"contentId":307,"date":308,"description":309,"extension":310,"meta":311,"navigation":312,"path":313,"rawbody":314,"robots":315,"schemaOrg":315,"seo":316,"sitemap":317,"stem":322,"__hash__":323},"posts\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets.md","Simplify Real-Time with Server-Sent Events Over WebSockets",{"type":7,"value":8,"toc":295},"minimark",[9,22,28,39,44,51,67,72,76,79,107,110,115,119,126,132,137,142,149,156,163,168,172,187,202,208,213,219,225,233,239,250,255,261],[10,11,12,13,17,18,21],"p",{},"When I started building with the ",[14,15,16],"strong",{},"web"," in 2018, I was fascinated by the ",[14,19,20],{},"real-time"," feature. Imagine, someone changes something on a page and the change is instantly visible for everyone. It was like magic for me.",[10,23,24],{},[25,26,27],"em",{},"I later learned that this magic comes with the cost of complexity.",[10,29,30,31,34,35,38],{},"At that time, I was learning ",[14,32,33],{},"Express",", and building a simple ",[14,36,37],{},"web server"," was already a challenge.",[40,41,43],"h2",{"id":42},"the-first-time","The first time",[10,45,46,47,50],{},"Later, for a school project, I had to build a very simple dashboard to manage ",[14,48,49],{},"IoT devices",", everything from scratch. Real-time was a requirement to broadcast the state of the devices from the server to every connected client.",[10,52,53,54,57,58,61,62],{},"I searched on the internet and every blog post, every tutorial was talking about ",[14,55,56],{},"WebSocket",". So, maybe that's the way to go. For this project, I learned and used ",[14,59,60],{},"Socket.IO",". The project is on GitHub at ",[63,64,66],"git-hub-link",{"repo":65},"barbapapazes\u002Fraspiot",".",[10,68,69],{},[25,70,71],{},"During the presentation, the demo effect touched me and everything was not working as expected.",[40,73,75],{"id":74},"with-a-framework","With a framework",[10,77,78],{},"I also tried to build a web application for students of my school to manage mentoring between students. I was still a beginner but projects are the best way to learn so I jumped into it.",[10,80,81,82,91,92,95,96,99,100,66],{},"I used ",[14,83,84],{},[85,86,90],"a",{"href":87,"rel":88},"https:\u002F\u002Ffeathersjs.com\u002F",[89],"nofollow","Feathers",", the API and real-time ",[14,93,94],{},"application framework",". It was probably too easy, so I decided to use ",[14,97,98],{},"Vue"," for the frontend with ",[14,101,102],{},[85,103,106],{"href":104,"rel":105},"https:\u002F\u002Fvuex.feathersjs.com\u002F",[89],"Feathers-Vuex",[10,108,109],{},"I never experienced something so hard for absolutely no value to my project. In retrospect, I think I wanted real time because it was fashionable (clearly, not a good reason).",[10,111,112],{},[25,113,114],{},"It was so complex that I never finished it.",[40,116,118],{"id":117},"websocket-is-complex","WebSocket is complex",[10,120,121,122,125],{},"On the web, we use a protocol called ",[14,123,124],{},"HTTP",". The request from a browser to a server is using HTTP.",[10,127,128],{},[129,130],"img",{"alt":124,"src":131},"\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fhttp.png",[10,133,134,136],{},[14,135,56],{}," is not HTTP. WebSocket is a protocol on its own. This is very important to know because this has consequences on how we can use it.",[10,138,139],{},[129,140],{"alt":56,"src":141},"\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fwebsocket.png",[10,143,144,145,148],{},"First, WebSocket is not native on ",[14,146,147],{},"Node.js",". We have to use an external library to use it. This could become a big deal if we have to integrate it into a complex project.",[10,150,151,152,155],{},"Second, WebSocket does not handle ",[14,153,154],{},"reconnection",". If the connection is lost, there is no built-in mechanism to reconnect. We have to handle it ourselves. In another way and despite its native support in browsers, we have to use it with a library to handle reconnection. This starts to be a lot of complexity and code to maintain.",[10,157,158,159,162],{},"Finally, WebSocket is not HTTP, and in your web server, you will need to handle two protocols and create a bridge between them. The bigger part is about ",[14,160,161],{},"authentication and authorization",". This could result in a lot of logic to create and maintain despite the fact that we could already have an authentication logic for HTTP. This also implies having a custom logic on the client to handle authentication and authorization. This is because HTTP is stateless and WebSocket is not.",[10,164,165],{},[25,166,167],{},"The thing I would love to hear when I was starting with WebSocket is that not every data needs to be real-time and simpler things are better than nothing.",[40,169,171],{"id":170},"the-other-way","The other way",[10,173,174,175,180,181,186],{},"The first time I heard about this tech was on a stream of ",[85,176,179],{"href":177,"rel":178},"https:\u002F\u002Fwww.twitch.tv\u002Fromainlanz",[89],"Romain Lanz",". He is a maintainer of ",[85,182,185],{"href":183,"rel":184},"https:\u002F\u002Fadonisjs.com",[89],"Adonis"," and masters the subject.",[10,188,189,190,193,194,197,198,201],{},"Sometimes, real-time can have value for a project that has ",[14,191,192],{},"charts",", ",[14,195,196],{},"data visualization",", information, asynchronous tasks, or even a ",[14,199,200],{},"chat",". But do you see the thing that all of these features have in common?",[10,203,204,205,66],{},"The client does not send, or few, information. Furthermore, the query time, between the client and the server, is not critical. So why would we need a bidirectional communication? And that does not interop well with HTTP? In 2024, ",[25,206,207],{},"I do not know",[209,210,212],"h3",{"id":211},"server-sent-events","Server-sent events",[10,214,215,218],{},[14,216,217],{},"Server-Sent Events"," (SSE) is a technology that allows a server to send events to a client. It is a unidirectional communication from the server to the client.",[10,220,221],{},[129,222],{"alt":223,"src":224},"SSE","\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fsse.png",[10,226,227,228,232],{},"The client asks for a resource using the ",[229,230,231],"code",{},"EventSource"," API and the server responds with a stream. This is an HTTP connection but that stays open to allow the server to send data to the client. Simple, right?",[10,234,235,236,238],{},"Bonus, this handle automatically ",[14,237,154],{}," without extra code.",[10,240,241,242,245,246,249],{},"On the internet, we can often read that SSE is bad, the client can't send data to the server. But do these people forget how internet works? Do they forget ",[229,243,244],{},"\u003Cform>"," or ",[229,247,248],{},"XMLHttpRequest","? Of course, the client can still send data to the server. Today, SSE does not have huge drawbacks.",[10,251,252],{},[25,253,254],{},"One day, we will build a simple chat using SSE and a form to send messages to demonstrate how simple and enjoyable the web can be.",[10,256,257,258,66],{},"In reality, there is a historical reason why WebSocket was better than SSE but that's not more the case in 2024 thanks to ",[14,259,260],{},"HTTP\u002F2",[262,263,266,271,275,281,284],"callout-read-more",{"text":264,"href":265},"Using Server-Sent Events","https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FAPI\u002FServer-sent_events\u002FUsing_server-sent_events",[10,267,268],{},[25,269,270],{},"For a game, WebSocket could be the best option to avoid the handshake between the client and the server.",[40,272,274],{"id":273},"finally","Finally",[10,276,277,278],{},"I think that we should always ask ourselves if we really need an instant bidirectional communication. If we do not need it, we should use SSE. It's simpler, it's HTTP, and it's powerful. ",[25,279,280],{},"Always weigh pros and cons before choosing, even if it's the most popular choice.",[10,282,283],{},"So, will you use SSE in your next project that needs real-time?",[10,285,286],{},[25,287,288,289,294],{},"It's possible to use SSE directly within our application since it's just HTTP. It's also interesting to know that ",[85,290,293],{"href":291,"rel":292},"https:\u002F\u002Fmercure.rocks\u002F",[89],"Mercure"," exists and can be useful for more complex projects.",{"title":296,"searchDepth":297,"depth":297,"links":298},"",2,[299,300,301,302,306],{"id":42,"depth":297,"text":43},{"id":74,"depth":297,"text":75},{"id":117,"depth":297,"text":118},{"id":170,"depth":297,"text":171,"children":303},[304],{"id":211,"depth":305,"text":212},3,{"id":273,"depth":297,"text":274},"c0a8f7ea-0bb1-4374-ad67-bf0d70c60eb0","2024-03-29","Discover powerful real-time web alternatives to WebSockets using Server-Sent Events (SSE) for simpler, more efficient solutions.","md",{},true,"\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets","---\ncontentId: c0a8f7ea-0bb1-4374-ad67-bf0d70c60eb0\ntitle: Simplify Real-Time with Server-Sent Events Over WebSockets\ndescription: Discover powerful real-time web alternatives to WebSockets using Server-Sent Events (SSE) for simpler, more efficient solutions.\ndate: 2024-03-29\n---\n\nWhen I started building with the **web** in 2018, I was fascinated by the **real-time** feature. Imagine, someone changes something on a page and the change is instantly visible for everyone. It was like magic for me.\n\n_I later learned that this magic comes with the cost of complexity._\n\nAt that time, I was learning **Express**, and building a simple **web server** was already a challenge.\n\n## The first time\n\nLater, for a school project, I had to build a very simple dashboard to manage **IoT devices**, everything from scratch. Real-time was a requirement to broadcast the state of the devices from the server to every connected client.\n\nI searched on the internet and every blog post, every tutorial was talking about **WebSocket**. So, maybe that's the way to go. For this project, I learned and used **Socket.IO**. The project is on GitHub at \u003CGitHubLink repo=\"barbapapazes\u002Fraspiot\" \u002F>.\n\n_During the presentation, the demo effect touched me and everything was not working as expected._\n\n## With a framework\n\nI also tried to build a web application for students of my school to manage mentoring between students. I was still a beginner but projects are the best way to learn so I jumped into it.\n\nI used **[Feathers](https:\u002F\u002Ffeathersjs.com\u002F)**, the API and real-time **application framework**. It was probably too easy, so I decided to use **Vue** for the frontend with **[Feathers-Vuex](https:\u002F\u002Fvuex.feathersjs.com\u002F)**.\n\nI never experienced something so hard for absolutely no value to my project. In retrospect, I think I wanted real time because it was fashionable (clearly, not a good reason).\n\n_It was so complex that I never finished it._\n\n## WebSocket is complex\n\nOn the web, we use a protocol called **HTTP**. The request from a browser to a server is using HTTP.\n\n![HTTP](\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fhttp.png)\n\n**WebSocket** is not HTTP. WebSocket is a protocol on its own. This is very important to know because this has consequences on how we can use it.\n\n![WebSocket](\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fwebsocket.png)\n\nFirst, WebSocket is not native on **Node.js**. We have to use an external library to use it. This could become a big deal if we have to integrate it into a complex project.\n\nSecond, WebSocket does not handle **reconnection**. If the connection is lost, there is no built-in mechanism to reconnect. We have to handle it ourselves. In another way and despite its native support in browsers, we have to use it with a library to handle reconnection. This starts to be a lot of complexity and code to maintain.\n\nFinally, WebSocket is not HTTP, and in your web server, you will need to handle two protocols and create a bridge between them. The bigger part is about **authentication and authorization**. This could result in a lot of logic to create and maintain despite the fact that we could already have an authentication logic for HTTP. This also implies having a custom logic on the client to handle authentication and authorization. This is because HTTP is stateless and WebSocket is not.\n\n_The thing I would love to hear when I was starting with WebSocket is that not every data needs to be real-time and simpler things are better than nothing._\n\n## The other way\n\nThe first time I heard about this tech was on a stream of [Romain Lanz](https:\u002F\u002Fwww.twitch.tv\u002Fromainlanz). He is a maintainer of [Adonis](https:\u002F\u002Fadonisjs.com) and masters the subject.\n\nSometimes, real-time can have value for a project that has **charts**, **data visualization**, information, asynchronous tasks, or even a **chat**. But do you see the thing that all of these features have in common?\n\nThe client does not send, or few, information. Furthermore, the query time, between the client and the server, is not critical. So why would we need a bidirectional communication? And that does not interop well with HTTP? In 2024, _I do not know_.\n\n### Server-sent events\n\n**Server-Sent Events** (SSE) is a technology that allows a server to send events to a client. It is a unidirectional communication from the server to the client.\n\n![SSE](\u002Fposts\u002Fsimplify-real-time-with-server-sent-events-over-websockets\u002Fsse.png)\n\nThe client asks for a resource using the `EventSource` API and the server responds with a stream. This is an HTTP connection but that stays open to allow the server to send data to the client. Simple, right?\n\nBonus, this handle automatically **reconnection** without extra code.\n\nOn the internet, we can often read that SSE is bad, the client can't send data to the server. But do these people forget how internet works? Do they forget `\u003Cform>` or `XMLHttpRequest`? Of course, the client can still send data to the server. Today, SSE does not have huge drawbacks.\n\n_One day, we will build a simple chat using SSE and a form to send messages to demonstrate how simple and enjoyable the web can be._\n\nIn reality, there is a historical reason why WebSocket was better than SSE but that's not more the case in 2024 thanks to **HTTP\u002F2**.\n\n\u003CCalloutReadMore text=\"Using Server-Sent Events\" href=\"https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FAPI\u002FServer-sent_events\u002FUsing_server-sent_events\" \u002F>\n\n_For a game, WebSocket could be the best option to avoid the handshake between the client and the server._\n\n## Finally\n\nI think that we should always ask ourselves if we really need an instant bidirectional communication. If we do not need it, we should use SSE. It's simpler, it's HTTP, and it's powerful. _Always weigh pros and cons before choosing, even if it's the most popular choice._\n\nSo, will you use SSE in your next project that needs real-time?\n\n_It's possible to use SSE directly within our application since it's just HTTP. It's also interesting to know that [Mercure](https:\u002F\u002Fmercure.rocks\u002F) exists and can be useful for more complex projects._\n",null,{"title":5,"description":309},{"loc":313,"images":318},[319,320,321],{"loc":131},{"loc":141},{"loc":224},"posts\u002Fsimplify-real-time-with-server-sent-events-over-websockets","CEHLIMXsbhLLw688IpmXpIdeIaNxVx-dHCnI0Fh56jU",1790086902010]