Skip to content

Tech Stack

The new backend is built as a modern TypeScript API service. Its stack is centered around NestJS for application structure, Prisma for data access, MySQL for persistence, and Docker-based workflows for local development and deployment packaging.

The stack is already opinionated in three ways:

  • modular NestJS service boundaries
  • schema-driven database access with Prisma
  • environment-based runtime configuration for local, staging, and production
  • TypeScript
  • Node.js
  • npm

The backend is compiled from TypeScript into a production dist/ build, but local development is centered around NestJS tooling and TypeScript-first development.

  • NestJS 11
  • @nestjs/common
  • @nestjs/core
  • @nestjs/platform-express
  • @nestjs/config

NestJS provides the module system, dependency injection, controller layer, middleware and guard composition, validation integration, and application bootstrap flow.

The current HTTP API layer is built with:

  • NestJS controllers and services
  • global validation via ValidationPipe
  • response normalization through a custom response interceptor
  • CORS configuration sourced from environment variables
  • Swagger/OpenAPI generation in non-production environments

This means the transport layer is not a raw Express API. It is a structured NestJS application with centralized validation and response formatting.

The backend currently uses:

  • @nestjs/jwt
  • @nestjs/passport
  • passport
  • passport-jwt
  • passport-local
  • bcrypt

This stack supports credential validation, token-based authentication, password hashing, and guard-based access control. In practice, authentication is one of the clearest first-class domains in the current backend.

  • Prisma
  • @prisma/client
  • mysql2

Prisma is the active data-access layer used by the application. It generates typed client access from schema.prisma, and the repository scripts are built around Prisma workflows such as generate, migrate, deploy, seed, studio, and schema pull.

  • MySQL 8.0

The backend expects a MySQL-compatible database for its primary persistence layer. Development also requires a shadow database because Prisma migrations rely on it for schema comparison and migration planning.

The application uses:

  • class-validator
  • class-transformer

These packages are integrated into NestJS DTO validation so request payloads can be transformed and validated consistently before they reach service logic.

The current backend includes:

  • nestjs-i18n

Localization is a built-in platform concern rather than an afterthought. The app module loads i18n globally, and Swagger is configured to expose Accept-Language expectations for clients.

The backend currently uses:

  • @sentry/nestjs
  • custom logger service
  • NestJS exception filters
  • health checks through @nestjs/terminus

This stack covers three operational areas:

  • exception capture and monitoring
  • structured application logging
  • service health and readiness reporting

The health endpoint is especially important because Docker Compose uses it as part of container orchestration.

The repository includes:

  • axios
  • @nestjs/axios

These support outbound HTTP calls to external services. Combined with the dedicated messaging module, this indicates the backend is designed to call external providers for notifications or platform integrations rather than remaining fully isolated.

  • Nest CLI
  • TypeScript compiler toolchain
  • ts-node
  • ts-jest
  • tsconfig-paths

These tools support local execution, test execution, compilation, and script-based Prisma seeding.

  • ESLint
  • Prettier
  • typescript-eslint
  • eslint-config-prettier
  • eslint-plugin-prettier

This is a standard TypeScript code-quality stack and indicates the repository expects automated formatting and lint validation as part of normal development.

  • Jest
  • Supertest
  • @nestjs/testing
  • jest-junit

The stack supports unit testing, e2e testing, coverage reporting, and CI-friendly test output generation.

  • Husky

Husky is used to prepare local Git hooks, which reinforces that the project expects basic automated checks during contribution workflows.

The backend uses:

  • @nestjs/swagger

Swagger is enabled outside production and is generated directly from the NestJS application. This makes the API stack partially self-documenting for development and staging use.

  • Docker Compose
  • Nginx as local reverse proxy
  • MySQL container
  • Mailhog for local email inspection
  • Makefile wrappers for common workflows

This development stack is more complete than a simple API container. It includes HTTPS-friendly local proxying, database provisioning, and local mail capture.

  • Docker
  • node:24-alpine
  • PM2 via pm2-runtime

The production image generates the Prisma client during build and starts the application through PM2. That suggests a containerized deployment model with process supervision inside the container.

There is one important stack-level nuance in the repository today:

  • Prisma is the clearly active persistence layer
  • @nestjs/typeorm and typeorm are still present as dependencies

At the moment, this looks like residual or transitional dependency baggage rather than an actual dual-ORM architecture. It should be treated as a cleanup opportunity unless a future module intentionally reintroduces TypeORM.

In practical terms, the backend stack can be summarized as:

  • NestJS for application structure and HTTP API composition
  • TypeScript for typed service development
  • Prisma plus MySQL for schema-driven persistence
  • JWT and Passport for authentication
  • Sentry, health checks, and custom logging for operations
  • Docker, Nginx, and Mailhog for local development infrastructure
  • Jest, ESLint, Prettier, and Husky for engineering quality

This is a solid modern backend foundation. It is already stronger than the legacy PHP platform in terms of modularity, typed contracts, migration discipline, and operational observability, even though several business domains have not yet been rebuilt on top of it.