Real-Time Application
In short: An application where data is exchanged between client and server (or between several clients) with no noticeable delay — e.g. chats, live dashboards, or multiplayer games.
In more detail: Classic HTTP is unsuited for real-time applications, since the client has to actively request (polling). Real-time capability is instead usually achieved via WebSockets, Server-Sent Events, or push services like Pusher, where the server can independently send updates to connected clients.
In Depth
The basic difference from classic web apps: with normal HTTP, the client always actively asks the server (“pull”) — the server can’t send something to the client on its own. There are several approaches for real-time features:
- Polling: the client repeatedly asks for new data at short intervals — simple to implement, but inefficient (many unnecessary requests) and never truly “real-time”, only as fast as the interval.
- Long polling: the client asks, but the server leaves the request open until there’s something new (or a timeout occurs) — less overhead than pure polling.
- WebSockets: a connection established once and left permanently open, over which both sides can send data at any time — today’s usual standard for genuine real-time features.
- Server-Sent Events (SSE): similar to WebSockets, but only in one direction (server → client), in exchange for being easier to implement.
Emzett uses the hosted service Pusher for real-time features (e.g. chat notifications), which provides WebSocket infrastructure without having to run your own WebSocket server. Important for all real-time approaches is low latency — the longer the delay between an event and its display, the less an application actually feels “real-time capable”.