Node.js Development

Node is the right tool for a small but important set of problems: systems that keep a great many connections open, systems that pass data around more than they work on it, and systems whose team already writes TypeScript everywhere else. Outside that, we will usually point you to 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 with ease, because an idle connection costs almost nothing. That is excellent, and it is why we use Node for live features: live tracking, chat, online status, editing together, dashboards that push updates instead of asking again and again.

The same trait is also the weak spot. One JSON parse of a 40 MB payload, one tight loop over a large list, one badly written regex meeting bad input, and the event loop stops. Every one of those ten thousand connections is now waiting on it. We treat CPU-heavy work as a firm line: it goes to a worker thread, a BullMQ job, or a different service entirely. We track event-loop lag as a key production number and set an alarm on it, because by the time users notice, you are already several minutes into a problem.

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 look after for years, we use NestJS: modules, dependency injection, decorators, class-validator at the boundary, and a structure so the twelfth developer puts their code where the first one would have. It is shaped like Laravel on purpose. Most Node codebases that go bad go bad because no one enforced a structure, not because they lacked clever ideas.

Where raw speed is the need and the surface is small, we use Fastify instead. It is clearly faster than Express, has schema-based checks 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 where each query is written, and Zod at every outside boundary, because a type is a promise made while building and the network does not care about your promises. Where the client is also TypeScript, tRPC removes the hand-written API contract and the kind of bug where the frontend and backend disagree about a field name.

Running it

Stateless containers behind a load balancer, one process per container, managed by tools rather than joined by hand. Redis for shared state and pub/sub between instances, because the moment there is more than one Node process, state kept in memory is a bug waiting to happen. BullMQ for background jobs with retries, backoff and a dead-letter queue. A clean shutdown that finishes running requests on SIGTERM. OpenTelemetry traces, and event-loop lag on the same dashboard as p95 latency.