httpBatchLink vs httpLink for High-Latency Network Environments

Direct answer

For users on high‑latency connections, httpBatchLink usually gives lower perceived latency because it reduces the number of round‑trips. Choose it unless you observe head‑of‑line blocking or hit server‑side payload limits; in those cases fall back to httpLink.

Confirmed facts

• httpLink sends each procedure in its own HTTP request → one TCP handshake and one round‑trip per call.
• httpBatchLink queues calls and sends them in a single POST → one handshake and one round‑trip for the whole batch.
• In networks with added latency (e.g., 150 ms one‑way), eliminating extra round‑trips cuts total latency roughly proportionally to the number of calls saved.
• If any call in a batch is slow, the whole batch waits for its response (head‑of‑line blocking).
• Large batches increase request size; API gateways or reverse proxies often enforce a maximum payload (commonly 1 MB–4 MB).

Likely explanation & trade‑off

The benefit of batching grows with the number of small, independent calls. The cost grows with:

1. Variability in call latency (slow calls block fast ones).
2. Total batch size approaching the gateway limit.
3. Need for individual error handling or optimistic updates that rely on per‑call responses.

When latency dominates and calls are uniformly quick, batching wins. When latency is moderate or call times vary widely, independent requests may feel faster despite extra handshakes.

Steps to decide for your case

1. Measure typical one‑way network latency (e.g., using ping or tc to add known delay).
2. Profile average procedure execution time on the server (fast vs. slow outliers).
3. Check the maximum request size allowed by your API gateway or ingress controller (look for client_max_body_size in NGINX, limit_request_body in Envoy, etc.).
4. Run a quick verification test (see below) with a batch size that reflects your typical call count.
5. If the test shows lower average completion time with batching and no payload errors, keep httpBatchLink; otherwise switch to httpLink.

Verification (safe, scoped)

Simulate latency on a Linux test interface (eth0 for example) and compare the two links.

# Add 150 ms one‑way delay (adjust interface as needed)
sudo tc qdisc add dev eth0 root netem delay 150ms

# Run a script that fires 20 small tRPC procedures via httpLink, measure time
# (replace with your actual client code)
node ./bench-httpLink.js

# Repeat with httpBatchLink (batch size 5)
node ./bench-httpBatchLink.js

# Remove the delay when done
sudo tc qdisc del dev eth0 root netem

Compare the average completion times. If httpBatchLink is consistently faster and no "413 Payload Too Large" errors appear, it is the better choice.
When to ask for a missing detail
If you do not know the gateway’s maximum request size, the recommendation may change: a large batch could be rejected, forcing a switch to httpLink. Please provide the payload limit (e.g., "API gateway allows up to 2 MB") if you are unsure.