When we reach for it
APIs and orchestration layers alongside a TypeScript front end, and anything I/O-bound where the work is waiting on other systems rather than on the CPU.
Web and application frameworks
Node.js development
A JavaScript runtime for the server, which lets one language, one set of types and one set of validation rules cover both sides of a request.
What we reach for first
When we would argue against it
Not for CPU-heavy work, and not as a default simply because the front end is JavaScript. Where a service has to hold a heavy load with predictable latency, we will propose Go and say why.
What it looks like in delivery
Node earns its place when the contract between client and server is shared rather than duplicated — one schema, validated at the boundary, generating both the runtime check and the type. That is a class of integration bug that stops existing.
Where this appears on the site
Published work that names it
- Rebuilding subscription billing and entitlements at SalteaCase study · architecture
- Closing the daily reconciliation break queue at ZafarinCase study · architecture
- Making offline receipt capture reliable in Vertigem's expense platformCase study · architecture
- Web developmentService · stack
- Mobile developmentService · stack
- API developmentService · stack
Derived from the stacks published on those pages, not written here — so this list cannot claim something the page it points at does not say.
Working in Node.js?
Tell us what it is running, what it costs you today, and what you need it to do next. A senior engineer will tell you what we would keep and what we would change.