Protocols, Proxies and Live Connections

A mobile app requesting an order, a server calling another service and a chat connection have different communication needs. A protocol defines how they exchange messages; a proxy forwards messages or connections on someone’s behalf.

Start with the direction of communication, the time each side can wait and what should happen when a connection disappears. Then choose a mechanism that satisfies that contract.

TCP supplies an ordered byte stream while a connection works. UDP sends datagrams without TCP’s delivery and ordering mechanisms. Applications using either still need failure handling. TLS protects a connection and authenticates the peer under the configured trust rules; it does not decide whether a user may edit an order.

HTTP describes requests and responses. HTTP/1.1 and HTTP/2 commonly use TCP; HTTP/3 uses QUIC over UDP. Version names are not a substitute for measuring latency, connection setup and compatibility. A timeout still leaves the outcome of a write uncertain.

REST is an approach to designing resource-oriented APIs, not a separate network transport. gRPC supplies typed remote calls and streaming through an interface definition; clients, intermediaries and deployed versions must support the chosen features. Neither approach makes a remote call as reliable as a local function.

Short polling repeatedly asks for updates. Long polling waits for an update or deadline before the next request. Server-Sent Events provide a server-to-browser event stream over HTTP. WebSockets support messages in both directions on a live connection. Select from the actual direction and frequency of updates.

These alternatives trade implementation simplicity against live delivery and connection operation.

A forward proxy represents clients making outbound requests, such as an organization’s controlled internet access. A reverse proxy fronts servers, routing inbound requests and sometimes terminating TLS or serving cached content. Load balancers and gateways can include reverse-proxy functions.

NGINX, HAProxy and Envoy are self-hosted options. Managed load balancers and gateways offer related functions with provider-specific policies. Distinguish a web server serving files from application code generating responses; one process can perform both roles.

Budget concurrent connections, message sizes, idle timeouts and reconnect bursts. Validate forwarded identity headers only from trusted intermediaries. Use MDN’s HTTP overview and the deployed proxy’s documentation for concrete behaviour.

GraphQL lets a client request selected fields through a typed schema. It can reduce some over-fetching, but a nested query can also create expensive resolver and database work. Bound query depth or cost, batch appropriate lookups and enforce access for each protected resource. A schema is not a permission system.

A backend for frontend, or BFF, shapes responses for a particular client such as a mobile app. It can aggregate calls and keep client-specific presentation needs out of general services. It also adds another contract and operating surface; use it when those differences justify the responsibility.

Compare a resource-oriented REST API, GraphQL and gRPC from client compatibility, caching, query flexibility, streaming and contract evolution. None automatically removes network failures or repeated effects. See GraphQL’s official learning guide.

Compare object Proxy with the network proxy responsibilities here. BFF shapes client interfaces, while aggregation owns a combined-response deadline and partial-result contract.

Choose the direction and failure rules before the protocol. Plan connection count and recovery alongside message throughput.

Use gateways for request policy and the chat design for durable delivery.