b90817b8e1
* Add project specs, gitignore the source PDF specs/batch-cooking-architecture.md and specs/batch-cooking-modele.md are the clean markdown transcription of "Projet batch cooking.pdf" (a scanned/image-only PDF, no extractable text). The PDF itself is gitignored — source working document, not meant to be committed. * Add Prisma schema for the documented data model Models every table from specs/batch-cooking-modele.md: users/household (user_profiles, house, diet, allergy, category), planning (planning, planning_item), and recipes (recipe, ingredients, step, tech_step, tech_step_mapping, sources). Two deliberate deviations from the literal spec doc, per project discussion: - recipe_ingredient (recipe <-> ingredients) carries quantity + unit. The spec describes a plain many-to-many with no extra fields, but a shopping list / batch-cooking calculation needs quantities. - step is modeled one-to-many from recipe (not many-to-many as labeled in the doc): the documented `order` column only makes sense scoped to a single recipe, which isn't reconcilable with steps being shared across recipes. Everything else follows the doc as-is, including field nullability choices made where the doc doesn't specify (e.g. user_profiles.house_id optional, recipe.source_id optional) and onDelete behavior (Cascade for owned child records, SetNull for optional references) — first draft, not meant as final production hardening. Verified: `prisma validate`, `prisma generate`, and a real `prisma migrate dev` against a local Postgres (via docker-compose) — the migration applies cleanly and produces the expected schema. README: documents the migrate command and a Postgres port-conflict gotcha hit during validation (a native Postgres service on this machine was already bound to 5432, intercepting the Docker container's connections). * Add COMMENT ON for every table and column in the init migration Descriptions pulled from specs/batch-cooking-modele.md's per-table field tables. The two tables not in the original spec (join tables recipe_ingredient, user_profile_allergy) get a comment explaining why they exist. Amends the still-unmerged init migration directly rather than adding a follow-up migration, since it hasn't been applied anywhere but this local dev database. Verified: `prisma migrate reset --force` reapplies cleanly, and a query against pg_description confirms every column of every project table has a comment (only Prisma's own internal _prisma_migrations table is uncommented, out of scope).
72 lines
2 KiB
Markdown
72 lines
2 KiB
Markdown
# Architecture technique — Projet Batch-cooking
|
|
|
|
> Documentation de l'architecture serveur/client de l'application.
|
|
|
|
---
|
|
|
|
## Vue d'ensemble
|
|
|
|
L'application repose sur une architecture **client-serveur** classique :
|
|
|
|
- Un **serveur** exposant une **API** (échanges standards) et un canal **websocket** (communication temps réel)
|
|
- Plusieurs **clients** (Client 1, Client 2, Client 3...) connectés simultanément au serveur
|
|
- Une base de données **PostgreSQL**
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
subgraph SERVER["Server"]
|
|
WS["Web socket"]
|
|
API["API"]
|
|
CALC["Calcul batch-cooking<br/><i>(TODO)</i>"]
|
|
IMPORT["Import d'une recette"]
|
|
IMP1["Import depuis source"]
|
|
IMP2["Traduction en étapes"]
|
|
IMP3["Sauvegarde"]
|
|
DB[("Database<br/>PostgreSQL")]
|
|
|
|
IMPORT --> IMP1 --> IMP2 --> IMP3 --> DB
|
|
CALC --> WS
|
|
end
|
|
|
|
C1["Client 1"]
|
|
C2["Client 2"]
|
|
C3["Client 3"]
|
|
|
|
API <--> C1
|
|
API <--> C2
|
|
API <--> C3
|
|
WS --> C1
|
|
WS --> C2
|
|
WS --> C3
|
|
|
|
style SERVER fill:none,stroke:#888,stroke-width:1px
|
|
```
|
|
|
|
---
|
|
|
|
## Composants
|
|
|
|
### API
|
|
Point d'entrée principal pour les échanges entre les clients et le serveur (requêtes classiques).
|
|
|
|
### Web socket
|
|
Canal de communication temps réel entre le serveur et les clients connectés.
|
|
|
|
### Module « Calcul batch-cooking »
|
|
Logique de calcul du batch-cooking (optimisation du planning/des recettes selon le planning). **Statut : TODO — reste à développer.**
|
|
|
|
### Module « Import d'une recette »
|
|
Pipeline d'ajout d'une recette, en trois étapes :
|
|
1. **Import depuis source** — récupération de la recette (via `sources`)
|
|
2. **Traduction en étapes** — découpage en `step` / `tech_step`
|
|
3. **Sauvegarde** — persistance en base de données
|
|
|
|
### Database (PostgreSQL)
|
|
Stockage de l'ensemble des données de l'application (voir le modèle de données pour le détail des tables).
|
|
|
|
---
|
|
|
|
## Notes
|
|
|
|
- Le module de calcul batch-cooking est le principal chantier restant côté serveur (TODO).
|
|
- Le websocket est utilisé pour la communication temps réel, en complément de l'API.
|