Skip to content

Architecture.md

Latest commit

 

History

History
160 lines (122 loc) · 7.85 KB

Architecture.md

File metadata and controls

160 lines (122 loc) · 7.85 KB

Architecture TaskHub

Document de référence : état actuel du dépôt et architecture cible alignée sur le document détaillé Plan backend et déploiement. Les choix d’implémentation fins (routes, champs exacts, librairies) restent dans le plan ; ce fichier en donne la vue d’ensemble cohérente.

1. Vue d’ensemble

TaskHub est une SPA React servie par Vite. Aujourd’hui, toute la persistance est dans le navigateur (localStorage pour les tâches, auth démo sans serveur).

La cible est une application en ligne multi-utilisateurs : API Node.js, MySQL comme source de vérité, auth réelle, isolation des données par compte, puis extensions produit (catégories, stats, exports, intelligence progressive) décrites dans le plan par sections 6 à 14.

2. État actuel (frontend seul)

flowchart LR
  subgraph browser[Navigateur]
    React[React + Router]
    RQ[TanStack Query]
    Zustand[Zustand auth]
    LS[(localStorage th_tasks)]
    CK[Cookies th_auth]
    React --> RQ
    RQ --> tasksApi[tasksApi.js]
    tasksApi --> LS
    Zustand --> CK
    Zustand --> LS
  end
Loading
Couche Rôle
Pages Home, Login, Register, Dashboard, Tasks, NotFound
Composants TaskCard, Modal, ProtectedRoute
Contexte ThemeContext (thème clair / sombre)
Données tâches src/api/tasksApi.js : CRUD simulé, clé th_tasks
Auth src/stores/authStore.js : cookie th_auth, th_user
Build Vite ; base: '/Taskhub/' dans vite.config.js

Limites pour la production multi-utilisateurs

  • Pas de vérification d’identité ni d’autorisation côté serveur.
  • Pas de user_id sur les tâches : liste partagée au niveau du navigateur.
  • Pas de stockage sécurisé des secrets (mot de passe) : à corriger avec le backend (plan §5).

3. Architecture cible

flowchart TB
  subgraph client[Client]
    SPA[React SPA Vite]
    SPA -->|HTTPS REST JSON| API
  end
  subgraph server[Serveur Node.js]
    API[API HTTP]
    Auth[Auth JWT ou sessions]
    Jobs[Jobs planifiés optionnels]
    API --> Auth
    API --> DBLayer[Accès MySQL]
    Jobs --> DBLayer
    Jobs -.->|rappels surcharge| API
  end
  subgraph data[Données]
    MySQL[(MySQL)]
    DBLayer --> MySQL
  end
Loading

3.1 Principes

  1. Source de vérité : MySQL (comptes, tâches, métadonnées métier).
  2. Frontend : présentation et appels HTTP ; jetons ou cookies httpOnly (plan §5, §7).
  3. Isolation : toutes les requêtes métier filtrent par user_id de l’utilisateur authentifié.
  4. CORS : origine du front (CLIENT_ORIGIN) explicitement autorisée (plan §4, §8).
  5. Exports et gros rapports : génération côté serveur (plan §10) ; fichiers ou URLs signées courtes durées.
  6. Rappels / tâches planifiées : traitements asynchrones (cron + file ou équivalent) quand la fonctionnalité sera activée (plan §12.5).

3.2 Modèle de données (alignement plan — par phases)

Phase 1 — Socle (plan §6, §9)
Indispensable avant le reste.

Table Rôle principal
users id, email (unique), password_hash, name, created_at, …
tasks id, user_id (FK), title, description, completed, due_date, created_at, updated_at

Phase 2 — Mesure et priorisation (plan §12.1, §12.3, §10)
Pour stats, exports fiables et filtres avancés.

  • tasks (colonnes additionnelles) : completed_at, priority (low | medium | high), éventuellement estimated_minutes plus tard.
  • Remplacement progressif du champ texte category par category_id (FK) lorsque la table categories est en service (plan §11).

Phase 3 — Organisation riche (plan §11, §12.6–12.7, §12.9)

Table Rôle
categories Catalogue + perso : user_id nullable, parent_id, name, color, icon, … (plan §11)
projects Regroupement de tâches, dates optionnelles (plan §12.7, §10.2)
tasks project_id nullable, parent_id nullable pour sous-tâches (plan §12.6)
tags / task_tags Mots-clés multiples (plan §12.9)

Phase 4 — Objectifs, récurrence, charge (plan §13.1, §12)

Concept Rôle
goals Objectifs mensuels / annuels ; liaison task.goal_id ou table de liaison (plan §13.1)
récurrence Champs ou table dédiée (rrule simplifié / fréquence) pour tâches répétitives (plan §13.1)
surcharge / réorg Règles métier sur agrégats (pas forcément de tables dédiées au début) (plan §13.1)

Les fonctionnalités IA (résumé d’export, assistants larges) restent des services optionnels branchés sur l’API, avec opt-in et quotas (plan §10.5, §13.2).

3.3 Surface API (vue d’ensemble)

Correspond au plan §6 (première version), enrichi par les blocs suivants du même document :

Domaine Exemples de routes Réf. plan
Auth POST /api/auth/register, login, logout §6
Tâches GET/POST/PATCH/DELETE /api/tasks §6
Catégories GET/POST/PATCH/DELETE /api/categories §11.6
Stats GET /api/stats/summary §12.3
Exports POST /api/exports/preview, POST /api/exports §10.6
Santé GET /api/health §9

Les routes tags, projects, goals suivront le même schéma REST une fois les tables créées (non exhaustif dans le plan initial — à ajouter au plan lors du premier commit server/).

3.4 Cartographie « plan → architecture »

Thème Contenu dans le plan Rôle architectural
§6–9 API minimale, React, déploiement, ordre de travail Fondation client / serveur / MySQL
§10 Exports filtrés, PDF / Office, preview, IA résumé optionnel Service export + stockage temporaire éventuel
§11 Catégories hiérarchiques, couleur, icône, perso Table categories + FK sur tasks
§12 Priorité, planification, stats, graphiques, rappels, sous-tâches, projets, tags, score Colonnes et tables listées §3.2–3.3
§13 Surcharge, réorg après retard, récurrence, objectifs en priorité Règles + tables goals / récurrence
§14 Liens utiles (dont lien vers ce fichier) —

3.5 Fichiers front à faire évoluer

  • src/api/tasksApi.js → client HTTP (fetch / axios) vers VITE_API_URL (plan §7).
  • src/stores/authStore.js, Login.jsx, Register.jsx → flux auth réel (plan §5, §7).
  • TanStack Query : queryKey incluant le contexte utilisateur ou session pour éviter les fuites de cache entre comptes (plan §7).
  • Nouveaux écrans ou sections au fil des features : exports (§10), gestion catégories (§11), dashboard stats (§12.3–12.4).

3.6 Hébergement

  • Front : build statique ; base Vite aligné sur l’URL réelle (plan §8).
  • API : process Node derrière HTTPS ; variables d’environnement de production (plan §8).
  • MySQL : instance dédiée ou managée, sauvegardes (plan §8).

4. Documentation associée

Document Contenu
Plan backend et déploiement Spec complète : auth, API, déploiement, exports (§10), catégories (§11), intelligence productivité (§12), priorités analyse (§13), liens repo (§14).

Règle de maintenance : lorsqu’un module (server/, migrations) est ajouté au dépôt, mettre à jour ce fichier (schéma réel, ports, noms de tables) et le plan (numéros de section inchangés si possible, ou note de migration de doc).

5. Révision de ce document

À actualiser dès que : dossier server/ présent, schéma SQL versionné, première URL de production API connue.