Node.js runs JavaScript on the server. We use it when a system needs to hold many connections open at once — live tracking, chat, notifications — or when the team already writes JavaScript on the front end and one language across the stack is worth more than any framework difference.
What is Node.js?
Node.js took the JavaScript engine out of Chrome and made it run on a server. The practical consequence is that one language covers the browser, the API and the build tooling, which removes a whole category of context-switching and lets validation logic be written once and used in both places.
Its other defining trait is how it handles concurrency. Most server languages give each request a thread, and a thread waiting on a database costs memory the whole time it waits. Node handles requests on a single loop, so a thousand connections that are mostly idle — a tracking screen polling for updates, a chat window sitting open — cost far less than they would elsewhere.
That same design is its weakness: a genuinely heavy computation blocks the loop and every other request waits behind it. Node is excellent at waiting and poor at thinking hard.
When we choose Node.js
When something on the screen has to update without a refresh. Live vehicle positions, order status moving through a kitchen, a notification arriving — these want a connection held open, and Node holds connections open more cheaply than the alternatives.
When the front end is already React or Vue and the team is small. Sharing types and validation between browser and server removes an entire class of integration bug, and for a team of three that saving is larger than any framework's feature list.
And when the job is an API gateway — a thin layer in front of several other services, mostly waiting on them. That is precisely the shape Node is best at.
When we do not use Node.js
For a content-managed site on shared hosting. Node needs a long-running process, which most cPanel plans do not provide reliably, and Laravel does the same job on infrastructure the client already owns.
For anything computation-heavy — image processing at scale, large report generation, data crunching. A single slow function blocks every other request, and Python or Go handles that shape far better.
And when the client's in-house team is PHP. Handing them a Node service means they cannot fix a production issue at 9pm, which is a real operational cost that outweighs the language-sharing benefit.
What we build with Node.js
Live tracking and status screens
Positions, statuses and alerts arriving on screen as they happen rather than on a refresh. The hard part is not the socket — it is what happens when the connection drops on a lift ride and has to resync without duplicating anything.
APIs that front several systems
One clean API in front of an ERP, a payment provider and a courier, so the app talks to one thing instead of three. Node spends most of its time waiting on those services, which is exactly what it is efficient at.
Voice and media pipelines
Accepting an audio clip, passing it to a transcription model, resolving the result into structured data. We built RetailDirect's voice ordering this way — audio in, a priced basket out, in over a hundred languages.
Real-time features
Live tracking, presence, notifications and collaborative editing — anything where a connection stays open. This is the workload Node was designed for and where it clearly beats a request-per-process runtime.
How we ship Node.js projects
TypeScript throughout, with the database schema generating the types rather than types being hand-written alongside it and drifting.
Process management matters more than people expect: a Node process that crashes must restart automatically, and one that leaks memory must be noticed before it takes the server with it. We set that up at deploy rather than after the first outage.
Anything genuinely slow goes to a queue rather than running inside the request. That is the single discipline that keeps a Node service responsive as it grows.
What Node.js costs you
The dependency tree gets large quickly, and a large tree is a large surface for security advisories. We keep dependencies deliberately few and audit them on a schedule rather than when something is reported.
Error handling is easier to get wrong than in most languages — an unhandled rejection can take the whole process down rather than failing one request. That is a discipline question, but it is a real one and it is why an unsupervised Node service is riskier than an unsupervised PHP one.
Dependency sprawl is the one to plan for. A modest Node project routinely pulls in hundreds of packages, each a maintenance and security surface. We keep the list short deliberately and audit it, because the alternative is a project that fails a security review a year later for reasons nobody chose.
Node.js questions we get asked
For holding many idle connections open, yes, clearly. For a normal request that reads a database and renders a page, modern PHP is comparable and sometimes faster. The honest answer is that the database design decides performance far more often than the language does.
Usually not reliably. Some cPanel plans offer a Node app manager, but it tends to be fragile. If shared hosting is fixed, we build with Laravel instead and reach the same outcome.
Laravel if the API sits alongside a website and the work is ordinary CRUD — you get more built in and cheaper hosting. Node if the API is real-time, or if the front end is already JavaScript and sharing types between the two is worth something.
For traffic that is mostly waiting on databases and APIs, yes — that is precisely what it is good at. Where it struggles is CPU-heavy work, because one blocked operation stalls everything else on that process. We move that kind of work to a queue or to Go.
Some cPanel plans now offer Node support, and it is usually more limited than it looks — restarts, memory limits and no control over the process manager. For anything past a simple API, budget for a VPS or a platform service instead.