Back-end runtime · in regular use
Node.js agency in Nice
JavaScript on the server: one team and one language cover both the interface and the back end.
What we do with it
Node.js at our clients, concretely
Used with NestJS on application services, and on mobile applications in React Native. We choose it when a single team must hold both front and back.
The limits
When we recommend something else
For data processing or AI, Python has an ecosystem with no equivalent.
Our work
Projects we delivered with Node.js
Ordelya
Restaurant management platform: back office, tablets, kiosks, screens and website.
Node.js: Next.js servers for the back office and website.
Angeles Immobilier
Multilingual website for a Côte d'Azur estate agency: listings, search and blog.
Node.js: Next.js server and API routes in production.
Read the Angeles Immobilier case study
Method
How we bring Node.js into a project
A Node.js project starts with a monorepo: the React or React Native app, the NestJS API and a shared package holding types and validation schemas. The repository is opened in your name from the outset, and strict TypeScript settings go in before the first feature, because tightening them later means revisiting code that has already been written.
The API is split into NestJS modules by business area (accounts, orders, notifications), each with its own controllers, services and tests. Database access goes through a typed ORM such as Prisma, whose migrations are versioned alongside the code. Jest or Vitest check the services and Supertest checks the endpoints. Deferred work goes through a Redis-backed queue rather than in-memory timers, which are lost every time the process restarts.
The API ships as a Docker image built once and promoted unchanged from staging to production, on hosting set up under your own credentials. Endpoint documentation is generated from the NestJS code, and the README explains the monorepo commands, the environment variables and how the mobile apps are published to the app stores.
For your business
What it changes in practice
For your users, an application built on Node.js and React Native applies the same rules on the web and on mobile: an input format rejected on the phone is rejected in the browser and on the server too, with no drift between versions. Real-time features, such as a notification when an order comes in or a dashboard that refreshes without reloading, can be added without an extra specialised server.
For you, a change often touches the interface and the API at once; a team working in a single language delivers it as one change, reviewed and tested together, rather than coordinating two parties. Shared typing also stops a field renamed on the server from quietly breaking the mobile app before anyone notices at release. One limit is worth knowing: the API and the website update as soon as they are deployed, whereas a fix to the mobile app still has to clear app store review.
Our reading of it
What we take away from Node.js
Node.js has a precise place in our work: the APIs that feed a web interface, and workloads where waiting dominates computing, such as calls to third-party services or connections held open. On that ground, a single process absorbs a great many simultaneous requests without extra machinery.
We do not write plain JavaScript on the server: everything goes through TypeScript, so a route’s contract is verified before deployment. Where the work turns into computation, data analysis or model handling, we move to Python rather than forcing Node into a role that is not its own. The service then ships to production inside a Docker image, which settles the question of which Node version the server happens to have.
Decision guide
Should you choose Node.js?
Node.js or PHP for our application's back end?
We choose Node.js when one team has to look after both the interface and the server, for instance a React or React Native app and its API. A single language, TypeScript, then covers both sides: data types are shared and developers move between them without switching toolchains. If the project is mostly a back-office full of business rules, Laravel is more direct, since it ships the admin layer that Node.js leaves you to assemble yourself.
NestJS or Express: which foundation for a long-lived Node.js API?
For an application expected to run for several years, we use NestJS. Express lets each developer organise the code their own way, which is fine for a small service but leads to inconsistent projects that are hard to hand over. NestJS enforces a modular structure, dependency injection and TypeScript by default, so two different teams find the same architecture. Express still makes sense for a microservice with a handful of routes or a throwaway prototype.
Node.js or Python for a project involving artificial intelligence?
If the AI part is limited to calling a model provider's API from a web application, Node.js is enough: official client libraries exist for JavaScript. Once you need to process data at volume, split and index documents, evaluate models or orchestrate processing pipelines, Python's ecosystem has no equivalent. In that case we keep Node.js for the application and its users, and hand the data processing to a separate Python service.
Client questions
What clients ask us about Node.js
Does one language for web, mobile and server really lower costs?
Mainly, it removes duplication. With React Native and a Node.js back end, validation rules, data types and part of the logic are written once and reused on the web, on mobile and on the server. You also need fewer distinct skill sets to maintain the whole thing. The saving depends on how much code is genuinely shared: an app that leans heavily on native phone features shares less.
Do the many npm dependencies create a security risk?
The risk is real: a Node.js project relies on hundreds of packages, some maintained by a single person. We reduce it by locking installed versions, choosing actively maintained libraries and scanning dependencies automatically on every change to catch known vulnerabilities. Security patches are applied as part of maintenance, rather than waiting for the next feature release.
Is Node.js here to stay, or will we need a rewrite in a few years?
Node.js is backed by the OpenJS Foundation and publishes long-term support releases maintained for several years. Because JavaScript is the language of web browsers, the pool of developers stays large. Rewrites are driven less by the runtime than by the libraries chosen, so we favour established frameworks such as NestJS and schedule the move from one long-term support release to the next before support ends.
Where should a Node.js API be hosted?
Shared hosting designed for PHP will not do: Node.js needs a process that runs continuously. We deploy the API in a container, on a virtual server or a container platform with a European provider, with a supervisor that restarts it if it stops and a reverse proxy in front. The hosting is set up under your own credentials, so billing, access and any change of provider stay in your hands.
Is Node.js suited to heavy computation, such as generating large reports?
Not inside the same process as the API. Node.js runs JavaScript on a single thread, so a long calculation holds up every other request while it runs. We therefore move that work out of the API into separate worker processes fed by a queue, and the user is notified once the result is ready. If the calculation is really data analysis, we hand it to a Python service instead.
Going further
Node.js sits within our Software development
A technology does not make a project. The method around it decides the outcome: scoping, prototypes, short cycles, and a clean way out.
Neighbouring technologies
A Node.js project in mind?
The first conversation is free. We will tell you plainly whether this technology is the right one, and if not, which is.
Updated on