Blog

Awaiting four independent API calls in sequence instead of parallel can triple your endpoint latency. Here's the pattern, the math, and how to catch it in review.

You've read "Node.js is single-threaded and non-blocking." Fine. But that sentence raises more questions than it answers. If it's single-threaded, who's doing the file I/O while your JavaScript runs?

If you're still writing pages/api/... files in a new Next.js project, stop. Route Handlers are the App Router's replacement, and they're meaningfully better — typed, streaming-capable, and built on the same Web platform APIs that Cloudflare.

Strip Express and Koa down to their core: a 30-line compose() function that chains async middleware with before/after hooks, short-circuit support, and error propagation.

`forEach` doesn't return a Promise, so `await` before it resolves instantly. Every async callback fires and is forgotten — this is how batch processors ship broken.

Your user-facing API is fine. REST, JSON, OpenAPI docs — it works, everyone can call it, no complaints. But internally, your Order service is calling the Inventory service 40 times per request.

You have 200 images to resize. The resize API is fast, but it throttles at 10 concurrent requests. If you throw Promise.all(images.map(resize)) at it, you'll blast all 200 simultaneously, collect a pile of 429s, and watch your retry logic.

Your endpoint is async but it still freezes the server. Here's the synchronous CPU work pattern that blocks Node's event loop and how senior devs catch it in review.

You've probably seen gRPC described as "REST but faster." That framing is technically true and practically useless.