This article explores Socket.IO v4, assessing some of the more important updates compared with v3 – the improvements they offer, and how to migrate.
A brief introduction to Socket.IO
Socket.IO is a JavaScript library for realtime web applications. It enables realtime, bi-directional communication between web clients and servers and has two parts – a client-side library that runs in the browser, and a server-side library for Node.js.
Generally speaking, Socket.IO is great for small-scale realtime projects, but it does not manage the complexity of a realtime system of any significant scale.
Scaling Socket.IO - practical considerations
Socket.IO 4 release
Released on 9th March 2021, Socket.IO 4 is a pretty significant update – a “major new version” – so it’s well worth diving into some of the most notable changes to see what they mean for realtime applications in the wild.
What’s new in Socket.IO 4?
In essence, Socket.IO 4 is an update of three parts. The most significant, are the breaking changes at API level on the server side.
What we’re seeing there is a general API clean-up. In isolation, that’s clearly a positive step, making the inputs more sane and removing ambiguity – potentially resulting in more stable code and fewer unexpected behaviors.
Alongside that, there are a number of bug fixes, including a tweak to the v2/v3 compatibility mode and a restoration of support for JS modules.
Part three is the addition of a range of new features, the most significant of which are the following.
Support for Typed Events
It is not news that TypeScript has taken the JavaScript community by storm, so added support for types is a really positive step. You can see the detail on the "Add strictly typed events" pull request (#1234) on the Socket.IO GitHub page, but essentially the new behavior looks like this:
Support for types is also interesting because it demonstrates that this requirement is traveling to all parts of the stack – and, as more fundamental libraries add support for types, it will undoubtedly improve the maintainability and longevity of Node.js projects.
Immutability
This one is half bug fix, half new feature – but either way, it's another positive step forward.
You can see the detail on the "make the io.to function immutable" code page on Socket.IO's GitHub, but the update can be pretty well summarized like this:
Before
io.to("room1");
io.to("room2").emit(...); // also sent to room1
// or with async/await
io.to("room3").emit("details", await fetchDetails()); // random behavior: maybe in room3, maybe to all clients
After
const operator1 = io.to("room1");
const operator2 = operator1.to("room2");
const operator3 = socket.broadcast;
const operator4 = socket.to("room3").to("room4");
operator1.emit(/* ... */); // only to clients in "room1"
operator2.emit(/* ... */); // to clients in "room1" or in "room2"
operator3.emit(/* ... */); // to all clients but the sender
operator4.emit(/* ... */); // to clients in "room3" or in "room4" but the sender
This update won’t directly address scalability, but it may provide some gains by preventing accidental modification and therefore improving code stability. Here is a more detailed exploration of Socket.IO scalability.
Migrating to Socket.IO 4
At the basic level, migrating to Socket.IO 4 should be straightforward because the Socket.IO protocol itself was not updated – so a v3 client will be able to reach a v4 server and vice-versa. That said, anyone already using the v2 to v3 compatibility mode, and therefore already running Socket.IO effectively in two states, might uncover some unwanted complexity and unknown issues when migrating to v4. Time will tell...
The bigger potential issue is if the API breaks, especially in something as fundamental as a library. Some of the issues that could emerge here are:
- Missing functionality and unforeseen issues: The sheer number of elements of a realtime layer that could be relying on an API feature that is no longer present or changed creates obvious problems – potentially some functionality could stop, and it will take time to track down and rectify those issues, which isn’t ideal in world where realtime is really no longer optional.
- Plug-in and language compatibility: Clearly, plug-ins designed to work with Socket.IO 3, and on which any number of realtime features may rely, may need updating to work with v4. The same goes for programming languages like Go and Java – and in all cases these updates are beyond user control, so it will be interesting to see how long they take to catch up. Socket.IO has gone dormant before.
Conclusion
This is, to all intents and purposes, a brand new API which brings new features and bug fixes, but also the risk that comes with an API break. It’ll be interesting to see how all this plays out as devs start to dig in and adapt to what is a pretty big set of changes.
Extra resource: Scaling Socket.IO - practical considerations
What do you think of this version? Are you thinking about migrating? Share your thoughts or ask any questions on Twitter @ablyrealtime.
