Node.js & NestJS

Overview

Node.js earns its place in two situations: when you need many concurrent connections doing very little work each — chat, notifications, live dashboards, streaming — and when sharing one language and one set of types across the front end and back end genuinely speeds a team up.

Where it is a poor fit, we say so. CPU-bound work blocks the event loop, and a single slow synchronous operation degrades every concurrent request. That is a design constraint, not a bug, and it should drive the decision rather than be discovered in production.

Why NestJS

Plain Express gives you complete freedom and, on a project of any size with more than one developer, that freedom becomes inconsistency. NestJS provides opinionated structure — modules, dependency injection, decorators, guards, interceptors and pipes — so an application written by four people over two years still has one shape.

It is TypeScript-first, has first-class support for REST, GraphQL, WebSockets and microservice transports, and its testing utilities make dependency injection genuinely useful rather than ceremonial. For a small service, Fastify or Express with a clear structure is lighter and perfectly reasonable; we choose by project size and team, not habit.

Real-time

This is where Node earns its keep. We build live features with WebSockets — Socket.IO where broad client support and automatic reconnection matter, native WebSockets where efficiency does — and Server-Sent Events where the flow is one-way and simpler is better.

The parts that are easy to get wrong and that we plan for explicitly: authenticating the socket connection rather than trusting the client; a Redis adapter so rooms work across multiple instances; reconnection with state resynchronisation, because clients will drop; backpressure handling so a slow consumer cannot exhaust server memory; and rate limiting per connection.

APIs

• REST with DTOs validated by class-validator or Zod, so untrusted input never reaches business logic unchecked.
• OpenAPI documentation generated from the code, so it cannot drift from reality.
• GraphQL where clients genuinely need flexible queries — with depth and complexity limits and DataLoader batching, since an unprotected GraphQL endpoint is an efficient denial-of-service tool.
• Consistent error shapes, correct status codes, and no stack traces leaking to clients.
• Versioning and deprecation handled deliberately rather than by breaking clients.

Background work and scale

• BullMQ on Redis for job queues, with retries, exponential backoff, dead-letter handling and visibility into what failed and why.
• Worker threads for the CPU-bound work that would otherwise block the event loop.
• Stateless services behind a load balancer, so scaling horizontally is a configuration change; sessions and shared state in Redis, never in process memory.
• Graceful shutdown that drains in-flight requests instead of dropping them on deploy.
• Connection pooling sized to the database, and clustering to use all available cores.

Security

• Every input validated at the boundary; nothing trusted because it came from your own front end.
• Helmet for security headers, CORS configured to an explicit allowlist rather than a wildcard.
• Rate limiting on authentication and on expensive endpoints.
• JWTs with short lifetimes and refresh token rotation, or server-side sessions where revocation matters more than statelessness.
• Dependency auditing in CI. The npm ecosystem's dependency depth is a genuine supply-chain risk and lockfiles alone do not address it.
• Secrets from the environment or a secrets manager, never in the repository.

Observability

A distributed Node system without observability is guesswork. We ship structured JSON logging with correlation IDs that follow a request across services, health and readiness endpoints for the orchestrator, metrics for latency, throughput and error rate, tracing where there are enough services to need it, and alerting on error budgets rather than on individual errors.

Testing and delivery

Jest or Vitest for unit tests, Supertest for HTTP-level integration tests, and Testcontainers to run against a real database rather than a mock that agrees with the code. Type checking, linting and audit as CI gates. Deployment in containers with health checks and a rollback path.

What you get

• A typed, documented API with validation at every boundary.
• Real-time features that survive reconnection and scale beyond one instance.
• Background jobs with retries and visible failure handling.
• Logging, metrics and health checks from day one, not added after the first incident.
• An honest recommendation when Node is not the right tool for the job.

Node handles ten thousand idle connections comfortably and one badly written synchronous loop very badly. Design around that and it is excellent.