What I learned from Googling WebSockets for 3 Hours
No I’m not an expert now
My research can be summarized in the below sentence:
WebSocket is a protocol and native API (not a library) that all modern browsers have implemented which allows for bi-directional communication with servers.
What does this mean? Let’s break it down.
WebSocket allows for bi-directional communication.
Bi-directional communication means that the browser and the server maintains open communication. This differs from the traditional HTTP protocol, in which the transaction begins with a request from the browser and ends with a response from the server. The base use-case of WebSockets can be described as the following:
- A browser navigates to a URL and performs a GET request
- The server responds with an message of ‘Upgrade’ type
- The connection is maintained until one party closes the connection
This is depicted in the below animation.
One big implication of this is that the server can send information to the browser without being prompted. This technology can be used for chat messengers, notifications and web games among others.
WebSocket is both a protocol and native API
WebSocket is a protocol which means it is an agreed upon format of communication between parties, in this case browsers and servers. One quirk of the WebSocket protocol is that it does not declare the format of the data being passed and leaves that up to the implementation. The browser side and server side need to be developed in tandem in order to understand one-another. All modern browsers have incorporated this protocol and it is available in the JavaScript WebSocket API. Servers need to be set up to handle a WebSocket connection specifically which is where some external packages come in.
WebSocket is not a library
There are various libraries which have extended the functionality of WebSockets. Some common features that developers may want for their site which the native WebSocket API does not implement:
- Selection of http vs WebSocket depending on browser support
- Browser reconnection if the connection goes down
- Message passing scheme with conversion to/from JSON
- A server-side concept of rooms where it’s easy to communicate with a group of connected users
- Connecting to a part of the server rather than just connecting to the server, like connection to a particular channel
- Server-side data structure with all connected users
- Storage of cookies and other headers present on the connection for each user (for identifying what user is connected)
- Server-side broadcast capabilities to send a messages to a group of users
- Configuration for firewall avoidance
- Configuration to coexist with load-balancers
Various libraries, paid or unpaid, fast or full-featured or easy to use can be found that implement some or all of the above features. The below libraries all seem modern enough to have their advantages.
Light and easy
- WS (standard, common, and easy to use)
- μWebSockets (lightest and fastest package)
- faye-websocket (ported from ruby)
Full Featured (but still free)
- Socket.io (more configuration than WebSockets, like custom headers)
- SocketCluster (builds on μWebSockets, with support for channels)
Paid
- Pusher (implements all of the listed features above)
What did I learn?
All in all, my impression of the ‘realtime web’ is that the field expands in complexity quickly when leaving the developer environment. The options some libraries offer are not required to build a simple app or webgame, but would be for a mature site with lots of users.
