Node.js Development
APIs, real-time features and back-end services built in Node.js and TypeScript
What Node is fast at, and why
Whoooop Ltd builds back ends in Node.js. A Node server runs your code on a single thread and hands the waiting — the database round trip, the call to a payment provider, the file being read — off to the operating system, then picks up whatever comes back first. So a few hundred connections that are mostly sitting idle cost it very little, while one request doing real arithmetic holds up everything queued behind it. That trade suits most of what a business site or web app actually does: take a form, check a record, call another company's API, send the reply. We've worked across the full stack for more than 15 years, so the Node we write is shaped by the database it reads from and the traffic it has to survive.
What we build with Node.js
APIs and back-end services
The server behind a site or app: it takes the request, talks to the database, and enforces the rules about who is allowed to do what. Usually REST, with GraphQL where clients genuinely need to ask for different shapes of the same data. Where the job is mostly wiring your existing systems to each other, our API development and integration page covers that side.
Real-time features
Live updates that arrive without the user reloading — a notification, a status that changes as an order moves, a dashboard that ticks over on its own. This is the case Node is built for: a connection that's open but quiet costs it almost nothing, so a lot of them can sit there waiting for something to happen.
Background and scheduled jobs
The work that shouldn't hold up a page: the confirmation email, the generated report, the overnight sync into another system. It goes onto a queue or a schedule, so the visitor gets an answer straight away and the slow part runs where it can't block anything.
One language across the stack
Back end and front end share a language, and in TypeScript they can share the type definitions themselves. Paired with our React front-ends, that means one developer follows a feature from the button through to the database without switching mental gears halfway.
The layer between your tools
A small service that sits in the middle: it takes a webhook from one system, reshapes the data, passes it to the next, and keeps a record of what happened — which is what you need the day something doesn't arrive and nobody can say where it stopped.
Inheriting an existing Node codebase
You have a Node app that runs and no longer have whoever wrote it. We start by getting it building on a current Node version, then work through what the audit is shouting about, separating advisories that actually reach your code from ones buried in a build tool. We'd rather keep a working service running than talk you into a rewrite.
When Node is the right call — and when it isn't
The single thread is also the limit. Hand Node something genuinely compute-bound — a large dataset to reconcile row by row, some machine-learning work — and it sits there with one core busy while everything else waits its turn. Python is usually where we'd take that, and we'd say so rather than build the wrong thing well. The other case worth naming is traffic that spikes and falls away again: Node can run on demand instead of on a server that idles between bursts, which our serverless development page covers.
Node.js and TypeScript
We write Node in TypeScript by default. A back end spends its life handling data it didn't create — a request body, a database row, a response from someone else's API — and typing that data at the edge forces the question of what you'll accept and what happens when the shape is wrong. Left unasked, it gets answered in production by whichever field turned out to be undefined. It matters again a year on, when whoever is editing the service no longer remembers what every function expected; there's more on how we use it across a codebase on our TypeScript development page.
Keeping a Node service healthy
Node's great asset is its package ecosystem, and it's also where a project goes off if nobody watches it. Dependencies fall behind, pick up security advisories, and drag in packages nobody chose. We keep them current, drop the ones a project has stopped earning, and pay attention to what each one brings with it. Speed is usually decided elsewhere, though — a slow Node back end is usually a slow query, so this work runs alongside our database design and development. And where Node is one part of a larger build, our web application development page sets out how we approach the whole thing, front end included.
Got a back end in mind?
Tell us what the server needs to do and we'll talk through whether Node.js is the right fit and how we'd build it.
Get in TouchFrequently asked questions
What is Node.js good for?
It is at its best when a server spends most of its time waiting — on a database, another company’s API, or a few hundred requests at once — rather than heavy calculation. That covers most of what a business site or web app does: take a form, check a record, call a payment provider, send the reply.
What do you build with Node.js?
APIs and back-end services, real-time features like live updates and notifications, and background or scheduled jobs such as confirmation emails, reports and overnight syncs.
Do you use REST or GraphQL?
Usually REST, with GraphQL where it genuinely helps. We pick based on how the data is actually used rather than fashion.