Skip to content
CAI
Software that uses CAICheck a score

meysamhadeli/booking-microservices-expressjs

30.7

Weak · 20 September 2026

6.9k

lines of production code

TypeScript

primary language

4

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

This system is a Node.js microservices application for flight booking, comprising Identity, Flight, Passenger, and Booking services. It provides REST APIs for user authentication, flight and seat management, and booking creation, utilizing PostgreSQL for data persistence and RabbitMQ for event-driven communication between services. The architecture follows a vertical slice pattern with CQRS, supported by shared infrastructure for observability, validation, and containerization.

Features

Add passenger lookup and listing endpoints

New API endpoints are now available for retrieving passenger data. Users can fetch a single passenger by ID via GET /api/v1/passenger/get-by-id and retrieve a paginated, searchable, and sortable list of all passengers via GET /api/v1/passenger/get-all. Both endpoints require JWT authentication and return data mapped to the PassengerDto.

src/passenger/src/passenger/features/v1 · high confidence

Added architecture diagrams for booking microservices and vertical slice patterns

New Excalidraw diagram files have been added to the assets directory to visualize system architecture. The \booking-microservices.excalidraw\ file provides a detailed diagram of the booking microservices structure, while \vertical-slice-architecture.excalidraw\ illustrates the vertical slice architecture pattern, including API and Application layers. These diagrams serve as visual documentation for developers to understand the system's design.

assets · high confidence

Added user creation consumer handler

A new consumer handler has been added to process 'UserCreated' events. When triggered, it creates a new passenger record in the system with a hardcoded age of 20 and passenger type set to MALE, logging the successful creation.

src/passenger/src/user · high confidence

Booking service initialization with Docker, environment, and build configuration

The booking service is now fully bootstrapped with essential infrastructure files. A multi-stage Dockerfile is provided to build and run the service on Node 22, including health checks and proper handling of the shared building-blocks dependency. Environment variables are defined in .env.development for local development, covering database (PostgreSQL), message queue (RabbitMQ), JWT authentication, and OpenTelemetry settings. Build and code quality tools are configured via TypeScript (tsconfig), ESLint, Prettier, and Jest (with sequential runner), while tsoa.json sets up API route generation and Swagger documentation output.

src/booking · high confidence

Flight service introduces aircraft, airport, flight, and seat domain models with database migrations

The flight service now includes the core domain entities for Aircraft, Airport, Flight, and Seat, along with their corresponding DTOs, TypeORM entities, and data mappers. A database migration script creates the necessary tables and relationships (e.g., flights linked to aircraft and airports, seats linked to flights), and a seed script populates initial data for development. Repository interfaces and implementations are provided for data access, and MediatR handlers are registered to support commands like creating aircraft/airports/flights/seats and retrieving flight details or available seats.

src/flight/src · high confidence

Identity service API routes and models are now generated via tsoa

The identity service now uses tsoa to automatically generate the Express route registration file (\routes.ts\). This change introduces auto-generated handlers for authentication endpoints (login, logout, refresh-token) and user management endpoints (create, get, update, delete). It also defines the corresponding request and response data models (such as \UserDto\, \LoginRequestDto\, and \TokenDto\) within the generated file, ensuring that the API contract is strictly enforced by the framework.

src/identity/src/routes · high confidence

Identity service application bootstrap and initial seed data

The identity service now includes its core application entry point (src/identity/src/app.ts) which initializes the Express server with standard middleware (helmet, compression, cors), integrates OpenTelemetry for tracing, Prometheus for metrics, and Swagger documentation in development mode, while also setting up database context, RabbitMQ, and MediatR handlers. Additionally, a user seed script (src/identity/src/data/seeds/user.seed.ts) has been added to automatically create an initial admin user with predefined credentials when the database is empty, facilitating local development and testing.

src/identity/src · high confidence

Identity service scaffolding with explicit database migrations and Docker support

The identity service now includes a complete development and deployment foundation. It introduces explicit TypeORM migration files (replacing automatic table synchronization) to manage the user and token database schema, alongside environment configuration files for development and testing. A multi-stage Dockerfile is added to build the service and its shared building-blocks dependency, exposing port 3333 with a health check. The project also establishes standard tooling configurations, including TypeScript, ESLint, Prettier, Jest, and TSOA for API documentation generation.

src/identity · high confidence

Initial booking domain model and service integration layer

This change introduces the core booking domain structure within the booking service, including the Booking entity and its corresponding DTO to define the data shape for reservations. It also establishes the HTTP client infrastructure required to interact with external services, specifically adding clients for the Flight and Passenger services to retrieve flight details, check seat availability, reserve seats, and fetch passenger information. Additionally, a mapping configuration is provided to handle the transformation between the internal Booking entity and the Booking DTO.

src/booking/src/booking · high confidence

Initial passenger domain model and data mapping

This change introduces the core data structures for the passenger feature, including the Passenger entity with fields for name, age, passport details, and type, alongside a corresponding DTO. It also defines the PassengerType enumeration (Unknown, Male, Female, Baby) and establishes the mapping logic to convert between the entity and DTO, specifically handling the translation of the passengerType field to passportType in the output.

src/passenger/src/passenger · high confidence

Initial project scaffolding and configuration for the flight service

This change introduces the foundational configuration files for the flight service, establishing the development and build environment. It includes TypeScript compiler settings (tsconfig.json) targeting ES2022 with CommonJS modules, ESLint and Prettier configurations for code quality, and Jest settings for sequential test execution. Additionally, it defines the service's runtime environment via .env.development (configuring ports, database, RabbitMQ, and OpenTelemetry endpoints), sets up Docker build stages for containerization, and configures tsoa for API route generation and Swagger documentation.

src/flight · high confidence

Initial project scaffolding with microservices infrastructure and documentation

This change introduces the foundational structure for a Node.js microservices application (Identity, Flight, Passenger, Booking). It adds a Docker Compose configuration to orchestrate the services along with their dependencies (PostgreSQL, RabbitMQ, Jaeger, Zipkin, OpenTelemetry Collector). An example environment file (.env.example) is provided to configure service ports, database credentials, and messaging exchanges. Additionally, the repository now includes a REST client file (booking.rest) for testing API endpoints, a CONTRIBUTION.md file outlining the Conventional Commits workflow, and a comprehensive README.md detailing the architecture (Vertical Slice, CQRS, Event-Driven), technology stack, and instructions for running the system via Docker Compose or Kubernetes.

(repo-wide) · high confidence

Initial setup of the passenger service scaffolding

The passenger service is introduced with its foundational configuration files, including environment variables for development (port 3355, JWT secrets, database and RabbitMQ settings), TypeScript compilation settings, and build tooling configurations for ESLint, Prettier, and Jest. A multi-stage Dockerfile is added to build the service and its shared building-blocks dependency, exposing port 3355 with a health check, while tsoa.json configures API route generation and Swagger spec output.

src/passenger · high confidence

Introduce Booking service with seat reservation capability

The new Booking service is now available, enabling users to create flight bookings. This service exposes a POST endpoint at /api/v1/booking/create that requires JWT authentication and accepts a request body containing passengerId, flightId, and description. The implementation integrates with the existing building blocks for logging, OpenTelemetry tracing, database context (PostgreSQL via TypeORM), and RabbitMQ messaging, ensuring consistent observability and infrastructure patterns across the platform.

src/booking/src · high confidence

Introduce Passenger service with standard infrastructure setup

The new Passenger service is now available, providing a default root route that returns the service name and configuring standard infrastructure including Express, Helmet, CORS, compression, Morgan logging, OpenTelemetry tracing, Prometheus metrics, and a PostgreSQL database context via TypeORM. The service also integrates RabbitMQ, MediatR handlers, and Swagger documentation in development mode.

src/passenger/src · high confidence

Introduce user domain model with role-based access and DTO mapping

This change establishes the core user identity structure within the identity service. It adds a User entity with fields for email, name, password, passport number, and a Role enum (USER or ADMIN), linking to authentication tokens. A corresponding UserDto is provided for data transfer, and a TypeMapper configuration is included to handle object mapping between the entity and DTO, ensuring fields like name, role, id, email, and passport number are correctly transferred.

src/identity/src/user · high confidence

Introduces token management infrastructure for authentication

This change adds the foundational data structures and mapping logic required for handling authentication tokens within the identity service. It introduces a \Token\ entity to persist access and refresh tokens along with their expiration and blacklist status, defines corresponding Data Transfer Objects (\TokenDto\, \AuthDto\) for API responses, and establishes a type-safe mapping between the database entity and the DTO layer. This provides the necessary backend support for issuing and managing user session tokens.

src/identity/src/auth · high confidence

New Passenger API endpoints for retrieving passenger details and lists

The passenger service now exposes two new REST endpoints: GET /api/v1/passenger/get-by-id to retrieve a specific passenger by ID, and GET /api/v1/passenger/get-all to list passengers with support for pagination, sorting, and search. Both endpoints require JWT authentication and return data conforming to the PassengerDto schema, which includes fields such as id, name, age, passportNumber, passportType, and timestamps.

src/passenger/src/routes · high confidence

New v1 API endpoints for booking, flight, and seat management

This change introduces a set of new REST API endpoints for the Booking, Flight, and Seat services, all implemented using a MediatR-based request handler pattern. Users can now create bookings (including seat reservation logic), manage aircraft and airport records, create and retrieve flight details, and manage seat availability and reservations. Each feature includes input validation via Joi, JWT security requirements, and publishes domain events (e.g., BookingCreated, SeatReserved) via RabbitMQ upon successful execution.

(repo-wide) · high confidence

New v1 User Management API endpoints

The identity service now exposes a v1 REST API for user management, implemented via tsoa controllers and a mediatr-js command pattern. Users can create, retrieve (by ID or paginated list), update, and delete user accounts. The create and update operations enforce email uniqueness, validate input using Joi, and encrypt passwords before storage. All mutations publish domain events (UserCreated, UserUpdated, UserDeleted) to RabbitMQ, and endpoints require JWT authentication.

src/identity/src/user/features/v1 · high confidence

New v1 identity authentication endpoints for login, logout, and token management

The identity service now exposes a v1 authentication API under /api/v1/identity, providing endpoints for user login, logout, and access-token refresh. The login endpoint accepts email and password, validates credentials, and returns both access and refresh tokens via a new GenerateToken handler. The logout endpoint accepts an access token and removes it from the repository, returning a 204 No Content status. The refresh-token endpoint validates the existing refresh token, removes it, and issues a new pair of access and refresh tokens. Token validation logic is centralized in a ValidateToken handler that checks token signatures and repository existence.

src/identity/src/auth/features/v1 · high confidence

Standardized building-blocks configuration, contracts, and error handling

The building-blocks library now provides a unified configuration system that validates environment variables using Joi and automatically loads the appropriate .env file based on the NODE\_ENV. It introduces a comprehensive set of domain contracts for the flight booking domain, including classes for Flight, Aircraft, Airport, Seat, and Passenger, along with enums for flight status, seat class, and seat type. Additionally, a centralized error handler has been added to standardize API responses using HTTP Problem Details for various exception types, and an HTTP context middleware is available to capture request and response objects for logging and tracing purposes.

src/building-blocks · high confidence

Behavioural changes

Centralized service and infrastructure initialization in booking module

The booking module now uses dedicated extension files to centralize the registration of dependencies and initialization of core services. HTTP clients for flights and passengers, the logger, MediatR handlers for booking creation, OpenTelemetry diagnostics with Prometheus metrics, RabbitMQ connections, and the booking repository are all explicitly registered or initialized through these new extension points, ensuring consistent setup of the application's internal components.

src/booking/src/extensions · high confidence

Centralized service initialization via extension modules

The identity and passenger services now use dedicated extension files to bootstrap core infrastructure. These modules handle dependency injection registration for repositories (user, auth, passenger), configure MediatR request handlers for domain features, initialize OpenTelemetry diagnostics with Prometheus metrics endpoints, and establish RabbitMQ connections with publisher and consumer bindings (such as the user creation consumer in the passenger service).

src/identity/src/extensions, src/passenger/src/extensions · high confidence

Explicit TypeORM DataSource and migration workflow for identity service

The identity service now uses an explicit TypeORM DataSource configuration (data-source.ts) instead of relying on automatic table generation, requiring manual migration generation and execution via npm scripts. A new database context (db.context.ts) initializes this connection, registers repositories, and runs the user seed data on startup. A readme has been added to document the migration commands.

src/identity/src/data · high confidence

Introduces explicit TypeORM migration strategy for booking data persistence

The booking service now manages its database schema through explicit TypeORM migrations rather than automatic synchronization. This change introduces a dedicated data-source configuration, a database context for initializing the connection and registering repositories, and a specific migration file to create the 'booking' table. Users benefit from a more controlled and auditable database evolution process, with provided scripts to generate and run migrations easily.

src/booking/src/data · high confidence

Introduces manual TypeORM migrations and a dedicated data access layer for the Passenger service

The Passenger service now uses explicit, hand-written TypeORM migrations instead of automatic schema synchronization, ensuring controlled database schema changes. This change introduces a new data access layer within the service that includes a centralized DataSource configuration, a DbContext initialization routine for dependency injection, and a PassengerRepository. The repository provides specific data operations including creating passengers, retrieving them by ID, and fetching paginated, sorted, and searchable lists, backed by a new database table and enum for passenger types.

src/passenger/src/data · high confidence

Test coverage

Added end-to-end test for user creation; Added integration test for user creation flow; Added test infrastructure and unit tests for user creation.

Dependencies

Initial dependency configuration for microservices

The booking, building-blocks, flight, identity, and passenger services have been initialized with their respective package.json files, establishing the core runtime and development dependencies. This includes Express for HTTP handling, TypeORM for database access, OpenTelemetry packages for distributed tracing, amqplib for RabbitMQ messaging, and various tooling libraries such as Jest, ESLint, and Prettier for testing and code quality.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

This is the PUBLIC form of this artifact. Findings are listed in full, but the details of SECURITY findings — which rule fired, in which file, on which line, and how to fix it — are deliberately withheld, and any secret-scanner results are excluded entirely. Where detail is absent here it was REMOVED FOR PUBLICATION; it is not missing from the analysis. The complete artifact is available from the repository owner.

Score

  • CAI 30 → 31 (+0.7)
  • Rubric changed (rubric-2026.08.17 → rubric-2026.09.15) — scores are not directly comparable.

Lenses

  • Code Health 74 → 83 (+8.5)
  • Architecture 62 → 83 (+20.5)
  • Maturity 56 → 67 (+11.4)
  • Readiness 30 → 30 (-0.2)
  • Security 80 → 55 (-24.4)
  • Domain Modelling 10 → 10 (+0.0)

Resolved (15)

  • Boundary-crossing change coupling: app.ts ↔ app.ts (src/booking/src/app.ts)
  • Boundary-crossing change coupling: app.ts ↔ app.ts (src/booking/src/app.ts)
  • Boundary-crossing change coupling: app.ts ↔ app.ts (src/booking/src/app.ts)
  • Coverage not included — suite not readable by the collector
  • Dependency hygiene not measured — no supported dependency manifest was read
  • Dormant codebase
  • High: security finding (details withheld)
  • High: security finding (details withheld)
  • No exposed public API
  • Scanner failed to run — not a clean result
  • Secret: jwt (booking.rest)
  • Secret: jwt (booking.rest)
  • Test reliability not included
  • The Goals of This Project section lists vertical-slice architecture but does not explain what slice each service represents or how slices interrelate. (README.md)
  • single-maintainer — knowledge-concentration (bus factor) risk

New (338)

  • Coverage not measured — JavaScript/TypeScript suite
  • Dependency hygiene PARTLY measured — npm pinning read, dependency currency not (no committed lockfile, so no resolved version to grade)
  • Documentation: no installation or build instructions (README.md)
  • Documentation: no usage examples (README.md)
  • High IaC: KSV-0014 (deployments/kubernetes/booking-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/flight-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/identity-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/jaeger-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/otel-collector-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/passenger-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/postgres-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/rabbitmq-deployment.yaml)
  • High IaC: KSV-0014 (deployments/kubernetes/zipkin-deployment.yaml)
  • High IaC: KSV-0109 (deployments/kubernetes/configmap.yaml)
  • High IaC: WD-COMPOSE-0002 (docker-compose.yml)
  • High IaC: WD-COMPOSE-0002 (docker-compose.yml)
  • High IaC: WD-COMPOSE-0002 (docker-compose.yml)
  • High IaC: WD-COMPOSE-0003 (docker-compose.yml)
  • High IaC: WD-COMPOSE-0003 (docker-compose.yml)
  • High IaC: WD-COMPOSE-0003 (docker-compose.yml)
  • …and 318 more

Changes since last survey

  • 3 commits — 3 feature/other, 0 fixes

By area

  • (root) — 2 commits
  • deployments/kubernetes — 1 commit

Notable commits

  • change: Merge pull request #18 from itachi5747/feature/add-dockerfile-docker-compose
  • change: docs: update README for running docker-compose and kubernetes to up and running whole application (#20)
  • change: feat: add kubernetes deployments for all services (#19)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

meysamhadeli/booking-microservices-expressjs was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 20 September 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 354f27e266cf01607c7c5cb9497ab8f675754112 — the exact code this score is about.
  • Scored under rubric-2026.09.15 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-28e75b8e3254.