I have been meaning to write engineering posts for some time to help product teams understand engineering. I will consciously keep it short and avoid tech jargon as much as possible to keep it simple. Let’s learn the basics of the Socket.IO library today.
Usually most apps use REST APIs, which can only handle uni-directional communication. In case of a chat app below, only the frontend mobile app can initiate communication with the backend. The backend can never initiate communication with the frontend on it’s own. It just patiently waits, lonely, sad and hoping that the frontend will talk to it. 😞😞😞
The limitation here is that the backend can send data to the frontend only after the frontend requests it. It cannot just update the frontend whenever needed. So in case of real time apps like a chat app, the frontend needs to constantly keep polling (sending requests to server every x seconds), which increases the server load.
Socket.io is a magic library that can handle bi-directional communication. The frontend and backend can initiate communication with each other anytime they want. It uses websockets (or polling as a backup in case websockets is not available) for bi-directional communication. Happy, happy backend! 😀😀😀
Gotcha! So where do engineers use it anyway?
Any feature or app that relies on real time communication will use the socket.io library. Think of messaging apps, stock ticker apps, live cricket score apps, multiplayer gaming apps like poker or ludo, social apps, live collaboration software. Event based architecture also keeps your entire system organized and maintainable. It’s easy to audit the flows and take action wherever needed.
Hope this post helps you next time the tech team mentions socket connections. Make sure to click on subscribe if you like this post and would like to be notified about new posts!