NODE.JS — THE BACK HALF.

//What I'm comfortable building#

HTTP APIs with real validation at the boundary. WebSocket servers — Nexus needed one that could fan out graph deltas to a few hundred connected clients without re-serialising the same payload per socket. Background jobs, scheduled work, webhook receivers, and the small services that sit between a frontend and something older and slower than it.

The most useful thing about knowing this layer is that it changes what I ask for. An endpoint returning a deeply nested object because it mirrors a database schema is a frontend problem, and being able to explain what shape I need and why — and roughly what it costs to provide — makes that a five-minute conversation instead of a standoff.

//What I've learned the hard way#

Streams are the answer more often than they seem. I once loaded a two-hundred-megabyte export into memory to transform it, which worked in development and fell over in production the first time two people exported at once. The streaming version was barely more code and used a constant few megabytes regardless of file size.

Also: the event loop is a shared resource, and one synchronous forty-millisecond operation blocks every other request. Anything CPU-bound belongs in a worker or a separate process, and "it's only slow occasionally" is a statement about your test data rather than about the code.

//The honest boundary#

Database design beyond straightforward relational modelling, infrastructure at scale and anything with a meaningful compliance surface — those need a specialist. I'll happily work alongside one.

Most of what runs here exists to support the front half: the rendering layer under Next.js, and the asset pipeline that feeds performance work.