Dogma-free backend architecture
Choose Node.js for its real qualities
Node.js runs JavaScript on the server side and relies on an event-driven model that is particularly effective for applications dominated by I/O. It's a great tool for some systems, but not an automatic answer for all projects.
PartITech analyzes the business domain, flows, load, skills and operations before recommending Node.js. The right decision may be a complete Node application, a targeted service, a backend for the interface or maintaining a more suitable existing technology.
- Use cases first
- The runtime responds to a real constraint
- LTS in production
- An anticipated release cycle
- Operation included
- Measurements, security and recovery
Numerous inputs-outputs
Contexts where Node.js is relevant
Node.js is particularly at home when an application coordinates many network operations without continuously running heavy calculations on the JavaScript thread.
API and aggregation
HTTP, GraphQL or backend for frontend services that combine multiple sources and adapt responses to interfaces.
Real time
Notifications, collaboration, activity tracking or dashboards that maintain many simultaneous connections.
Event processing
Message consumption, webhooks, service orchestration and flow processing dominated by network expectations.
Server JavaScript rendering
Front-end applications using a framework that also executes JavaScript for rendering, routes or data access.
Tooling and automation
Commands, pipelines, transformations and internal tools that benefit from the project's JavaScript ecosystem.
TypeScript Team
Sharing of skills, types and models between interface and server, without assuming full sharing of the code.
Limits are part of the choice
When Node.js is not the best option
The event model does not automatically make an application fast. A long synchronous operation blocks the event loop and penalizes all requests served by the process.
Architectural point
Node.js is not “single-threaded only”
The main JavaScript code runs on an event loop, while Node also uses the system, a pool of threads and, if necessary, separate workers or processes. Parallelism exists, but must be designed explicitly.
Connecting backend and JavaScript architecture- CPU intensive calculation performed directly in query processing.
- Much more mature business ecosystem in another language.
- Stable existing application whose rewriting does not add value.
- Small site without specific server logic or need for a permanent runtime.
- Team without ability to maintain Node dependencies and operations.
Intensive computing
Isolate or change runtime
Images, video, simulation or scientific calculation may require a specialized worker, a dedicated service or other technology.
Rewrite
Measure value
Changing language does not remove business complexity and can cause years of functional stabilization to be lost.
Ecosystem
Evaluate dependencies
The size of the npm catalog does not replace quality, maintenance or control of the supply chain.
TypeScript
Possible typing
Node.js can be developed perfectly with TypeScript. The need for static typing is therefore not sufficient reason to rule it out.
Life cycle 2026
Use an LTS version in production
The Node.js project recommends Active LTS or Maintenance LTS branches for production applications. A Current version is used to prepare the ecosystem and should not be chosen as an LTS by default.
Node.js 24 “Krypton”
Latest LTS branch released. It constitutes the natural target of a new project when its dependencies and its environment are compatible.
Status: LTS.
Node.js 22 “Jod”
LTS branch still supported. An existing application can remain there according to its schedule, while preparing for its next version upgrade.
Status: LTS.
Node.js 26
Current branch in August 2026. It allows you to anticipate new features, but is not yet the reference LTS branch for production.
Status: Current.
Node.js 20 and earlier
These branches have reached their standard end of life. They must no longer constitute the runtime of an exposed application without additional support.
Objective: Migrate to an LTS.
Production and continuity
The runtime is not enough to make the service reliable
Saturation, failure and restart must be designed
We observe event loop delay, memory, response times, errors, message queues, and availability of external dependencies. Long operations are limited, moved or queued depending on their nature.
Security also covers Node versions, dependency locking, secrets, permissions, deployment images, and responding to security advisories.
- Timeouts, cancellation and concurrency limits
- Event loop delay and memory consumption
- Idempotent workers, files and processing
- Clean shutdown and crash recovery
- Structured logs, metrics and traces
- Locked and updated dependencies
The official Node.js release schedule specifies the Current, LTS and end-of-life branches.
Deciding with evidence
Our method for validating Node.js
We test the riskiest hypotheses before committing the entire product to an architecture.
Frame the domain
Journey, business rules, data, integrations, volume, availability and regulatory constraints.
Qualify the load
I/O and compute share, concurrency, message sizes, peaks and expected response times.
Evaluate the existing
Code, team, infrastructure, libraries, tools and real cost of coexistence or migration.
Compare architectures
Full node, targeted service, BFF, specialized worker or maintaining the current solution.
Prototype the risk
Critical load, integration or processing performed with representative data and constraints.
Test for failure
Timeouts, API unavailability, saturation, restart, duplicates and process termination.
Define exploitation
Deployment, scalability, observability, security, backups and on-call responsibilities.
Formalize the decision
Argued choice, known limits, target version, performance budget and maintenance schedule.
An exploitable architecture
What we deliver
- Decision note and comparison of options
- Architecture of services, data and events
- Prototype of major technical risks
- TypeScript foundation and development conventions
- Functional testing, load and failure scenarios
- Containerization and deployment procedure
- Dashboards, alerts and logging
- Version policy and dependency maintenance
PartITech Expertise
Node.js when the project warrants it
Since 2012, we have been developing and maintaining tailor-made applications in several ecosystems. This experience allows us to integrate Node.js where its model provides a concrete advantage, without transforming a runtime choice into a project objective.
We can intervene on the framing, development, resumption of an existing service or migration to a maintained LTS branch.