Architecture globale

Le principe

Il y a un seul cerveau : l'API. Elle garde les données dans PostgreSQL et applique toutes les règles. Le site web et l'application mobile sont deux « clients » : ils affichent des écrans et envoient des requêtes HTTP à l'API. Ils ne se parlent jamais entre eux.

Comme les deux clients utilisent la même API, une modification faite sur le web (un manager corrige une heure) apparaît immédiatement sur le mobile, et inversement.

Ce qui tourne en production

L'ensemble est hébergé sur deux machines virtuelles Google Cloud :

• tm-prod fait tourner l'application elle-même ;
• tm-tooling fait tourner Jenkins, l'outil qui construit et déploie automatiquement.

Le mobile n'est pas hébergé sur ces serveurs : il est installé sur les téléphones et appelle api.time.jostud.com comme le site web.

Le chemin d'une modification

Quand un développeur fusionne du code dans main, rien n'est fait à la main :

Le détail est dans D'un commit à la prod.

Comment les clients s'authentifient

Les deux clients utilisent le même mécanisme :

1. POST /api/auth/login avec email et mot de passe.
2. L'API répond avec deux cookies HttpOnly (invisibles pour le JavaScript) : un jeton d'accès valable 1 h et un jeton de renouvellement valable 30 jours.
3. Elle renvoie aussi un jeton CSRF dans la réponse, que le client renvoie dans l'en-tête x-csrf-token à chaque requête.
4. Quand le jeton d'accès expire, le client appelle POST /api/auth/refresh et rejoue sa requête.

Côté mobile, c'est expliqué pas à pas dans Authentification.