ADR-010 — Backend Runtime, Framework and Module Format¶
Status: ACCEPTED — I1-B2 Technology Decision Gate
Accepted: 2026-09-21
Decision¶
The Touriffique backend technology baseline is:
| Concern | Decision |
|---|---|
| Runtime | Node.js 24 |
| Language | TypeScript with strict mode |
| Framework | NestJS 12 |
| Initial HTTP adapter | Express |
| JavaScript module format | Native ESM |
| Package manager | pnpm |
The backend remains the modular monolith accepted in ADR-004 and ADR-009.
HTTP adapter evolution¶
The initial API runtime uses NestJS with the Express adapter.
When parts of the platform are later extracted into independently deployed HTTP-based services, Fastify is the preferred HTTP adapter to evaluate/adopt unless a concrete ecosystem or compatibility requirement justifies another choice.
This is not a rule that every future microservice must use Fastify. A service using Kafka, queues, scheduled jobs or another non-HTTP transport uses the transport appropriate to its responsibility.
TypeScript policy¶
Application code uses TypeScript strict mode.
Exact supplementary compiler flags, lint rules and static-analysis thresholds belong to implementation and I1-B14 quality-gate design unless later promoted to architectural requirements.
Package strategy¶
The backend uses pnpm and remains one backend repository/application codebase with API and worker entry points.
Engine boundaries are application/module boundaries; they are not required to become separately published npm packages merely to enforce architecture.
A separate internal-package or workspace decomposition may be introduced later only when it provides a concrete build, ownership, reuse or extraction benefit.
Version policy¶
The accepted major runtime/framework lines are Node.js 24 and NestJS 12.
Compatible patch/minor/security upgrades within those accepted major lines are allowed without reopening this ADR unless an upgrade changes a frozen platform assumption or introduces a breaking migration.
Consequences¶
- new backend code is authored as native ESM rather than carrying a CommonJS migration burden;
- NestJS provides the initial module/DI/application-context structure for API and worker runtimes;
- Express maximizes initial middleware/ecosystem compatibility;
- future independently deployed HTTP services have a path toward Fastify without forcing an early adapter migration;
- pnpm lockfile/install behavior becomes the backend package-management baseline;
- database, ORM, validation, queues, testing and deployment technologies remain separate decisions.