Backend : vue d'ensemble

L'API est le cœur de TimeManager : le site web et l'application mobile n'ont aucune règle à eux, ils lui demandent tout. C'est elle qui décide qui peut pointer, qui voit les heures de qui, ce qu'une semaine validée bloque, et qui garde l'historique de chaque modification.

En bref

Sujet	Détail
Dossier	timemanager-api/
Langage	Elixir 1.17 sur Erlang/OTP 26
Framework	Phoenix 1.8 (API JSON, sans pages HTML)
Base de données	PostgreSQL 17, via Ecto
E-mails	Swoosh, envoyés par Brevo en production
Documentation interactive	/api/docs (Swagger)
Adresse	api.time.jostud.com/api
Clients	le site web (cookies) et l'application mobile (jeton Bearer)
Tests	environ 460, lancés par Jenkins avant chaque déploiement

Ce que fait l'API

Les deux moitiés du code

Le code est coupé en deux, et c'est la première chose à comprendre :

• timemanager/, le métier. Les règles : pointer, valider une semaine, accepter une correction. Ce code ne sait rien d'HTTP, de JSON ni des cookies.
• timemanager_web/, le web. Il reçoit une requête HTTP, vérifie qui appelle et ce qu'il a le droit de faire, appelle le métier, puis répond en JSON.

Le métier sert donc aussi sans passer par HTTP : les données de démonstration et les tests l'appellent directement. Et une règle n'est écrite qu'une seule fois.

Par où commencer

Je veux…	Lire
comprendre Elixir, Phoenix et Ecto	Les bases à connaître
lancer l'API sur mon poste	Lancer le projet
savoir où est quoi	Organisation des dossiers
suivre une requête de bout en bout	Le trajet d'une requête
connaître les tables	Base de données
essayer les routes	la page Swagger : /api/docs

Le principe qui revient partout

L'API ne fait confiance à personne. Le site web et l'application vérifient déjà beaucoup de choses pour le confort de l'utilisateur, mais toute règle est aussi vérifiée par l'API, puis souvent une dernière fois par une contrainte de la base de données. Un client modifié ou un appel direct avec curl ne peut contourner aucune règle.