Pusher

In short: A hosted service for real-time communication (WebSockets) between server and browser — e.g. so that a chat message appears immediately in all other open browser windows without the page having to be reloaded.

In more detail: In the browser you subscribe to a “channel”; the server “publishes” events on this channel, and Pusher forwards them in real time to all connected clients. Private channels (e.g. personal chats) need a dedicated server endpoint (auth endpoint) that checks on every connection attempt whether the user is allowed to access this channel at all.

Our context: At Emzett it powers the internal team chat, the open community chat and the new direct messages between friends — all three use the same existing Pusher auth endpoint, but with different access checks in front of it.

In Depth

Real-time communication on the web can basically be solved in two ways: polling (the browser itself asks at short intervals, “anything new?”) or a WebSocket connection (server and browser keep a permanently open connection over which both sides can send messages at any time, without a new request being needed). Polling is simpler to build, but causes unnecessary traffic and a noticeable delay; WebSockets are instant, but more work to operate yourself — a permanently open socket per connected user doesn’t scale trivially across many server instances at once. Services like Pusher take over exactly this scaling problem and offer a simple publish/subscribe API instead.

The channel concept knows three visibility levels: public channels (anyone can subscribe without a check), private channels (need a server-side auth check when subscribing) and presence channels (like private ones, additionally with an automatic list of who is currently online — handy for “online” indicators in a chat).

// Server: send an event to a channel
await pusher.trigger(`chat-${roomId}`, "new-message", { text, userId })
 
// Browser: receive the event
pusherClient.subscribe(`chat-${roomId}`).bind("new-message", (data) => { ... })

Dropped connections and reconnects

A WebSocket connection can drop at any time — the mobile network changes, Wi-Fi is briefly gone, the laptop goes into standby. The Pusher client handles automatic reconnecting in the background, but messages sent DURING the interruption are lost for this client, unless the application additionally stores them permanently (e.g. in the database) and fetches them afterwards on reconnect. For a chat this means: Pusher provides the “live” delivery, but the actual message history still has to be persisted separately — Pusher itself is not storage, only a delivery mechanism.

Presence channels in detail

Presence channels extend private channels with automatically managed participant lists: as soon as a client subscribes successfully, a pusher:subscription_succeeded event fires with all currently present users; afterwards pusher:member_added/pusher:member_removed report joins/leaves in real time — handy for “who’s online right now” indicators, without having to rebuild this yourself with your own heartbeat requests.

See also: Rate Limiting, Sockets, Service