Increasing httpBatchLink batchWindow in tRPC v11 for low-traffic serverless workloads

Direct Answers

1. Supported batchWindow values: The batchWindow option accepts any positive integer (milliseconds). The default is 1. There is no upper bound enforced by the library, but values above a few hundred milliseconds become impractical for interactive UIs.
2. When batching reduces invocations: Batching only merges calls that occur within the same window. If the time between two procedure calls exceeds the configured batchWindow, they are sent in separate HTTP requests. For sporadic traffic, you need a window larger than the typical gap between calls you want to combine.
3. Weighing latency vs. invocation cost: Every added millisecond of batchWindow delays the first call in a batch by that amount. In low-traffic scenarios, the invocation savings are roughly proportional to the fraction of calls that fall inside the window. Measure your actual call intervals and cold-start penalties before increasing the window beyond 10–50 ms.

How httpBatchLink Batching Works

The link starts a timer on the first procedure call. Subsequent calls arriving before the timer expires are appended to the same HTTP request. When the timer fires, the batched request is sent. This is a pure client-side debounce; the server sees a single request with an array of procedure calls.

Practical Configuration Steps

1. Set batchWindow in your client link creation:

   import { httpBatchLink } from '@trpc/client';\n\nconst trpc = createTRPCClient<AppRouter>({\n  links: [\n    httpBatchLink({\n      url: '/api/trpc',\n      batchWindow: 30, // milliseconds\n    }),\n  ],\n});

2. Verify batching in the browser Network tab: multiple procedure calls should appear as a single POST to /api/trpc with a JSON array body.
3. Compare serverless invocation logs before and after the change under realistic traffic to confirm reduced function starts.

Trade‑off Checklist

• Cold starts: Batching does not eliminate the cold start of the first request in a burst; it only reduces the number of subsequent cold starts if the burst spans multiple would‑be invocations.
• Timeout limits: Ensure the combined request payload and processing time stay within your platform’s HTTP timeout (often 30–60 s).
• User‑perceived latency: A 100 ms window adds up to 100 ms delay to the first call. For user‑facing mutations, keep the window ≤ 20 ms unless you have data showing longer gaps.

One Diagnostic Detail Needed

What is the typical inter‑call interval (in milliseconds) between the tRPC procedures you want to batch? If you can share a histogram or rough percentiles (e.g., p50, p95) from client‑side timestamps, I can recommend a concrete batchWindow value.