Node.js Development

Node is the right tool for a narrow, important set of problems: systems that hold a great many connections open, systems that pass data around more than they compute on it, and systems whose team already writes TypeScript everywhere else. Outside that, we will usually point you at Laravel or Go and be honest about why.

The event loop is the whole design, and it is also the whole risk

Node handles ten thousand idle WebSocket connections on a single process without breathing hard, because an idle connection costs almost nothing. That is genuinely excellent, and it is why we reach for Node on real-time tiers: live tracking, chat, presence, collaborative editing, dashboards that push rather than poll.

The same property is the failure mode. One synchronous JSON parse of a 40 MB payload, one tight loop over a large array, one badly-written regex meeting a hostile input, and the event loop stops — and every one of those ten thousand connections is now waiting on it. We treat CPU-bound work as a hard architectural boundary: it goes to a worker thread, a BullMQ job, or a different service entirely. We instrument event-loop lag as a first-class production metric and alarm on it, because by the time users notice, you are already several minutes into an incident.

NestJS when the system will outlive its first team

Express is fine for a service that fits in one engineer's head. For anything a team will maintain for years, we use NestJS: modules, dependency injection, decorators, class-validator at the boundary, and a structure that means the twelfth developer puts their code where the first one would have. It is deliberately Laravel-shaped, and that is the point — most Node codebases that go bad go bad from an absence of enforced structure, not from a shortage of clever ideas.

Where raw throughput is the requirement and the surface is small, we use Fastify instead. It is meaningfully faster than Express, has schema-based validation and serialisation built in, and does not pretend to be a framework for a large team.

Types all the way to the database

TypeScript in strict mode, no exceptions and no any smuggled in to make a deadline. Drizzle or Prisma for the data layer so the schema is typed at the query site, Zod at every external boundary because a type is a compile-time promise and the network does not care about your promises. Where the client is also TypeScript, tRPC removes the entire hand-written API contract and the class of bug where the frontend and backend disagree about a field name.

Running it

Stateless containers behind a load balancer, one process per container, orchestrated rather than clustered by hand. Redis for shared state and pub/sub between instances, because the moment there is more than one Node process, in-memory state is a bug waiting for its moment. BullMQ for background jobs with retries, backoff and a dead-letter queue. Graceful shutdown that drains in-flight requests on SIGTERM. OpenTelemetry traces, and event-loop lag on the same dashboard as p95 latency.