HTTP/2, WebSockets, and gRPC
HTTP/2 multiplexes multiple requests over a single TCP connection and supports header compression. WebSockets provide full-duplex persistent connections over HTTP. gRPC is an RPC framework using HTTP/2 and Protocol Buffers for efficient service-to-service communication.
HTTP/2 = a multi-lane highway on one road (multiplexing). WebSockets = a walkie-talkie (both sides talk anytime). gRPC = a drive-through intercom with a strict menu (proto contract) -- fast, typed, no misunderstandings.
HTTP/2: multiple concurrent requests on one TCP connection (no need for connection pooling tricks), server push, header compression (HPACK). No head-of-line blocking at HTTP level (but still TCP-level HOL blocking — solved by HTTP/3). WebSockets: upgrade from HTTP/1.1, bidirectional real-time communication (chat, live updates, gaming). Server maintains persistent connection per client — stateful, requires careful scaling. gRPC: uses HTTP/2 for multiplexing + Protocol Buffers for binary serialization (10x smaller than JSON, faster parse). Supports streaming (client, server, bidirectional). Strongly typed via .proto contracts. Ideal for internal microservice communication.
gRPC vs REST trade-offs: gRPC has a steeper learning curve (.proto files, code generation), limited browser support (requires gRPC-web proxy), but offers 5–10x lower latency and bandwidth vs JSON/REST for high-frequency internal calls. Proto3 backward compatibility: adding fields is safe (unknown fields ignored); removing requires a deprecation cycle. gRPC streaming enables patterns impossible in REST: server-streaming for real-time subscriptions, bidirectional streaming for collaborative editing. WebSocket scaling challenge: a persistent connection to a specific server makes horizontal scaling and zero-downtime deploys harder. Solutions: nginx upstream keepalive + connection draining, or a dedicated WebSocket gateway layer backed by a pub/sub system (Redis pub/sub, Kafka) so any server can send a message to any connected client regardless of which server holds the connection.
For client-to-server APIs consumed by browsers and mobile clients, I'd use REST/HTTP with HTTP/2 enabled at the edge. For real-time bidirectional communication (chat, live notifications), WebSockets via a dedicated gateway backed by Redis pub/sub for fan-out across multiple gateway instances. For internal microservice-to-microservice communication, gRPC — the binary protocol and strong typing with code generation reduce boilerplate and surface schema mismatches at compile time rather than runtime.
Using WebSockets for every 'real-time' use case. Server-Sent Events (SSE) over HTTP/2 handle most unidirectional server-push needs (notifications, live counts) without the WebSocket overhead and scaling complexity. Use WebSockets only when you need true bidirectional communication.