Push Data to Browsers and Micro-services with WebSocket
WebSocket started as a competitor of HTTP AJAX requests. When we needed real-time communication from the browser or data push from the server, they came out as a nice alternative to legacy solutions such as long polling or comet. Because they were using a
- PDF / 214,691 Bytes
- 20 Pages / 504 x 720 pts Page_size
- 61 Downloads / 154 Views
Push Data to Browsers and Micro-services with WebSocket Why WebSocket? WebSocket started as a competitor of HTTP AJAX requests. When we needed real-time communication from the browser or data push from the server, they came out as a nice alternative to legacy solutions such as long polling or comet. Because they were using a persistent connection and no headers, they were the fastest and lightest option if you had a lot of small messages to exchange. Today though, HTTP2 is being more and more adopted and does have a persistent connection and data push. So why WebSocket? Well, first, WebSocket APIs target application code, not just server code. So, on all implementations, you can hook on the connection life cycle, react to disconnection, attach data to the session, etc. A very handy feature to create robust interactions and pleasant user experiences. Then, while HTTP2 does have compressed headers, WebSocket has no headers at all, making the whole footprint even lower. In fact, HTTP2 implementations force encryption even for non-sensitive data, while in WebSocket you have the choice on where and when to spend your machine resources, and activate SSL or not. What’s more, HTTP2 servers tend to use push to send static resources (CSS, images, JS, etc.) to the browsers, but it’s not generally used for pushing application data. This is where WebSocket shines: pushing notifications to users, propagating events, signaling changes. . . 285
© Mark Williams, Cory Benfield, Brian Warner, Moshe Zadka, Dustin Mitchell, Kevin Samuel, Pierre Tardy 2019 M. Williams et al., Expert Twisted, https://doi.org/10.1007/978-1-4842-3742-7_8
Chapter 8
Push Data to Browsers and Micro-services with WebSocket
However, there is one strange thing about WebSocket: it is not tied to a domain name, and browsers don’t need any special setup for doing CORS. You can actually connect from a web page to a local WebSocket server on your computer without any warning. It can be seen as a pro, or a con, depending on what you need to do. All those characteristics make WebSocket a great tool for your website notifications, chat, trading, multi-player games, or real-time charts and graphs. Needing less to say, you don’t have to limit yourself to that, as you can leverage it as a link between all your components, and make it the communication layer that coordinates your whole system. This means that your web server can talk to your caching processes or your authentication platform through WebSocket. Or that you can manage a herd of IoT1 devices. After all, the Raspberry Pi has de facto Python support. Overall, WebSocket is a safe bet now, as it is available in most major browsers, down to, and including IE10. That’s about 94% of the market, according to caniuse.com. Worst case scenario, you can find shims for the few remaining browsers. As the WebSocket and HTTP handshakes are compatible, it will likely work on any network that lets through HTTP. You can even share the 80 and 443 ports between the two protocols.
WebSocket and Twisted On the server side, We
Data Loading...
