JK
>CHARGEMENT // CHARGEMENT
INITIALISATION DE LA VUE
Terminénestjspostgrestypescriptjesteslintdockergithubactionspostmanswagger
Backend de Microservices
Architecture moderne de microservices avec NestJS, PostgreSQL et Docker orchestrée par une passerelle API Gateway centralisée.
Problème et solution
Séparation nette des responsabilités entre le routage (API Gateway), la logique métier (services autonomes) et la persistance des données pour un déploiement indépendant.
Fonctionnalités
- Services découplés pour les Produits et les Commandes
- API Gateway pour le routage centralisé et la sécurité
- Base de données PostgreSQL orchestrée avec Docker Compose
- Structure monorepo gérée par TurboRepo
- Pipeline CI/CD GitHub Actions avec déploiement automatique sur Docker Hub
- Suite complète de tests unitaires avec Jest
Stack technique
| Technologie | Version | Objectif | Pourquoi ce choix |
|---|---|---|---|
| TypeScript | ^5.7.3 | Primary language for all services | Type safety, NestJS ecosystem standard |
| NestJS | ^11.0.1 | Application framework | Modular architecture, dependency injection, TypeScript-first |
| TypeORM | ^0.3.27 | ORM for PostgreSQL access | Active Record/Repository pattern, NestJS integration |
| PostgreSQL | 15 | Primary database | JSONB support, ACID compliance, reliability |
| Docker | — | Containerization for all services | Consistent environments, reproducible deployments |
| Turborepo | ^2.5.8 | Monorepo task orchestration | Fast parallel builds, caching, npm workspaces integration |
| GitHub Actions | — | CI/CD pipeline execution | Free for public repos, tight Git integration |
| Jest | ^30.0.0 | Unit testing framework | NestJS default, snapshot support |
| Swagger | ^11.2.0 | API documentation | Auto-generates OpenAPI from decorators |
Architecture
Core System Components
- API Gateway for routing requests to internal services
- Products & Orders service as independent NestJS services
- Docker Compose orchestration
- PostgreSQL container
Infrastructure
- GitHub Actions CI (lint, test, build)
- Docker Hub CD image deployment
- Environment variable management
Structure du projet
.github
workflows
apps
api-gateway
orders-service
products-service
libs
common
docker-compose.yml
Points d'API
API Gateway (port 3000)
| Méthode | Route | Objectif |
|---|---|---|
| GET | /products | List all products |
| GET | /products/:id | Get product by ID |
| POST | /products | Create product |
| PATCH | /products/:id | Update product |
| DELETE | /products/:id | Delete product |
| GET | /orders | List all orders |
| GET | /orders/:id | Get order by ID |
| POST | /orders | Create order |
Products Service (port 3001)
| Méthode | Route | Objectif |
|---|---|---|
| POST | /products | Create product |
| GET | /products | List all products |
| GET | /products/:id | Get product by ID |
| PATCH | /products/:id | Update product |
| DELETE | /products/:id | Delete product |
Orders Service (port 3002)
| Méthode | Route | Objectif |
|---|---|---|
| POST | /orders | Create order |
| GET | /orders | List all orders |
| GET | /orders/:id | Get order by ID |
Conception de la base de données
product
| Colonne | Type | Notes |
|---|---|---|
| idPK | SERIAL | Auto-generated primary key |
| code | VARCHAR | Product SKU/code |
| name | VARCHAR | Product display name |
| description | VARCHAR | Product description |
| price | DECIMAL | Product price |
| image | VARCHAR | Image URL |
No explicit indexes beyond primary key. No unique constraints on code.
order
| Colonne | Type | Notes |
|---|---|---|
| idPK | SERIAL | Auto-generated primary key |
| customer | JSONB | Stores {name, phone} |
| products | JSONB | Array of {id, name, rate, qty} |
| totalAmount | DECIMAL | Total order amount |
Products stored as JSONB snapshot — intentional denormalization. No foreign keys to product table.
No foreign key relationships. Order.products is a JSONB snapshot — orders are self-contained records that do not reference the product table. Product price changes do not affect existing orders.
Décisions de conception clés
Shared PostgreSQL Database
Décision : Both services connect to the same PostgreSQL instance and database (procura_db)
Pourquoi : Simplifies development and deployment — one database to manage
Avantages : Simpler infrastructure, lower resource usage, easier local development
Compromis : Violates database-per-service principle, creates hidden coupling, makes independent scaling harder
JSONB for Order Products
Décision : Order entity stores product data as JSONB rather than foreign key references
Pourquoi : Decouples order data from product lifecycle — orders are immutable snapshots
Avantages : Orders are self-contained, product changes don't affect historical orders
Compromis : No referential integrity, data duplication, no automatic product validation on order creation
API Key Authentication
Décision : Simple static API key in x-api-key header, compared against environment variable
Pourquoi : Simplest possible authentication for demonstration purposes
Avantages : Minimal implementation, no token management, no state
Compromis : No user identity, no fine-grained permissions, key is static and shared
HTTP-based Inter-service Communication
Décision : API Gateway communicates with downstream services via synchronous HTTP (Axios)
Pourquoi : Simplest approach for synchronous request-response pattern
Avantages : Easy to understand, debug, and test; standard HTTP tooling
Compromis : Synchronous coupling, no retry/circuit breaker, no async processing
Multi-stage Docker Builds
Décision : Each service uses a 3-stage Dockerfile (deps → builder → runner)
Pourquoi : Minimizes final image size and attack surface
Avantages : Production images contain only runtime dependencies and compiled code
Compromis : Build time for each stage, no layer caching optimization for src changes
TypeORM synchronize: true
Décision : Both services use synchronize: true in TypeORM config
Pourquoi : Auto-creates/updates database schema from entities during development
Avantages : No migration files needed, schema stays in sync with code
Compromis : Dangerous in production — can cause data loss on schema changes
Tests
Jest ^30.0.0 with ts-jest ^29.2.5•34 tests unitaires
Ce qui est testé
- API Gateway: root health check, all proxy operations (products + orders)
- Products Service: controller methods (create, findAll, findOne, update, remove)
- Products Service: service methods (create, findAll, findOne, update, remove)
- Orders Service: controller methods (create, findAll, findOne, id conversion)
- Orders Service: service methods (create, findAll, findOne)
Couverture manquante
- Integration tests with real database
- API Gateway ↔ Service integration tests
- Middleware tests for API key validation
- Validation error scenario tests
- Error path tests (404, 500 scenarios)
Défis clés
- Coordonner plusieurs services tout en garantissant l'isolation des pannes
- Configurer des pipelines CI/CD fiables pour plusieurs images Docker
Apprentissages clés
- Modèles d'API Gateway pour centraliser les requêtes entrantes
- Mise en réseau de conteneurs et orchestration Docker Compose