WebSockets
In this chapter, we replace long polling with WebSockets, and then compare our design with GraphQL subscriptions and a real-time database.
After reading this chapter, you should be able to:
- Explain why typing indicators make long polling costly
- Read a WebSocket’s opening handshake and explain why a frame costs less than a request
- Decide which messages go over the WebSocket and which stay on the REST API
- Explain how the server sends a new message to the open connections of a room’s members, and why removing a member must also update them
- Explain how a WebSocket is closed, how the server finds a dropped connection, and how the client reconnects
- Explain what open WebSockets cost a server, and why one server can hold Courselore’s
- Decide whether a feature needs polling, long polling, or a WebSocket, and what goes over the WebSocket
- Explain what GraphQL subscriptions add, how their results travel, and what they still need from the server
- Explain what a real-time database does, and how subscribing our server to its changes changes the design
- Explain why a server normally sits between the client and the database, and what changes when clients connect directly
- Distinguish a backend as a service from a database as a service