Building Real-time Apps using WebSockets
The constant need for communication has only strengthened in the last few decades. More and more people are interacting through digital platforms. This shift in the overall communication dynamic of humans is very dependent on that “connection” feeling as real as possible. With changes coming almost daily in the world of technology, this paradigm shift from outdated HTTP requests evolved into a robust and life-like transmission.
Almost still in its infancy, WebSockets have only been around for 10–15 years. This advanced technology makes it possible to open a two-way interactive communication session between the user's browser and a server. This eliminates the need for each HTTP request needing to be triggered by the user. This “real-time” experience allows for the development of a multitude of apps including:
- Chat Applications
- Social Media Updates
- Live Gambling Odds and Wagers
- Stock Market Tickers
Why WebSockets?
As mentioned before, WebSockets provide a more dynamic user experience. It allows the user to be fully invested in what is happening without the need for more traversing. This additional traversing can also lead to navigation issues and has a higher chance of failure.
WebSockets vs REST
We’ve been told time and time again that RESTful HTTP is ideal for most applications, however that’s not always the case. The big limitation that holds HTTP back is the need for requests and pulls. This means that the browser would have to poll the server for new information by repeating requests every few seconds to see if there was anything new. WebSockets helped push this forward by being flexible. It meant that not only could data be transferred to and from servers to browsers but also Peer-to-Peer (P2P) between browsers.
Time and Speed
By now, we understand that there are some serious pitfalls between the two, but how do they really differ? When compared to a WebSocket library like Socket.io, we can see how many requests happen per second based on the requests made.
Socket.io is a JavaScript WebSocket library. It allows for bi-directional communication between web clients and servers. Socket.io utilizes two main components, a client-side library that is seen on the browser and a server-side library that is run in Node.js. Both of these components have similar APIs, so the implementation on either end is seamless.
Utilizing these JavaScript libraries is shown to be very useful as the requests require less time. In today's technological environment more often than not, time is everything.
The main reason the speed for Socket.io is faster is due largely to the fact that there are fewer Bytes needed to be transferred. By having fewer operations and data to send, to get the same response the Socket can hold existing pertinent information and only refresh what is changing. HTTP however, would need to action the response, and pull having to gather some of the same information again.
Business Solutions
Understanding WebSockets is only half the battle. We also need to know the best way to implement them and how to get the most out of our efforts. Being able to get the most out of them can also sometimes prove to be a difficult task. Thankfully there are many “out-of-box” solutions available like Pusher.
Pusher places itself between servers and clients as an intermediary along with the WebSocket and, allows the developer to use their solutions to add various features to their website through the Pusher API including:
- Continuously Streaming Dashboards
- Presence Indicators
- Realtime Maps
- Gaming and Chat.
Developers can leverage these tools and widget-like products to add additional features that will all work seamlessly between themselves. The big draw to these solutions is that they’re highly customizable and can be initialized in only a few minutes.
Security
Similar to HTTPS, WebSockets have their own “wss” protocol that requires an authentication mechanism with a transmission layer to further enforce security.
This prevents any DoS attacks one could conjure up seeing that there is an unlimited number of messages getting to the server at any point. Some of the main security risks include:
- Authentication Control
- Risk of Sniffing to prevent information leakage
- Cross-Site WebSocket Hijacking (CSWH)
There are many tools like Burp and Zap that can allow you to intercept and modify WebSocket frames on the fly. Another great tool is Chrome DevTools as it allows you to see the WebSocket traffic in real-time. When auditing a WebSocket the same HTTP requests would apply (injection tests, access rights tests, workflow tests).
Closing
WebSockets are a great option to aid in simplifying communication between your server and users. If your project is being built, this option proves itself to be far superior to the HTTP method. The big draw and advantages overall include:
- Continuous Connection between client and server allowing the client and server to share data asynchronously
- Full Duplex Communication via a handshake request
- Low-Latency due to cutting out the HTTP requirements
If you are, however, working on an existing project that does not currently use WebSockets it may prove difficult to implement as the architecture of the entire application would need to be updated and possibly overhauled to work with them which may not be efficient.
Overall, WebSockets aim to make our work easier and more efficient which they have successfully done. With support for a multitude of implementations, wide browser support, and its cross-origin communication, WebSockets allow for easy and dynamic integration in many modern applications.
