78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
# ADR 002 — Découplage auth-client et api-client
|
|
|
|
**Statut :** Accepté
|
|
**Date :** 2026-04-17
|
|
**Décideur :** Hermann
|
|
|
|
---
|
|
|
|
## Contexte
|
|
|
|
Le frontend doit :
|
|
1. Obtenir un token JWT auprès de Supabase (authentification).
|
|
2. Envoyer ce token au backend Hono sur chaque requête API (autorisation).
|
|
|
|
L'approche initiale proposée était un seul fichier `api-client.ts` contenant un intercepteur qui appelle directement le SDK Supabase pour récupérer le token avant chaque requête. Cette approche couple fortement le client HTTP à Supabase.
|
|
|
|
## Options envisagées
|
|
|
|
### Option A — API client avec intercepteur Supabase intégré
|
|
|
|
```typescript
|
|
// api-client.ts
|
|
import { supabase } from './supabase'
|
|
|
|
async function apiFetch(path: string) {
|
|
const { data } = await supabase.auth.getSession()
|
|
return fetch(`${API_URL}${path}`, {
|
|
headers: { Authorization: `Bearer ${data.session?.access_token}` }
|
|
})
|
|
}
|
|
```
|
|
|
|
- Avantages : code court, un seul fichier, familier aux développeurs juniors.
|
|
- Inconvénients : couple définitivement l'HTTP layer à Supabase, rend impossible le test du client API sans mocker Supabase entier, bloque toute migration future d'auth (ex : passage à Auth0, Clerk, auth maison).
|
|
|
|
### Option B — Deux fichiers distincts
|
|
|
|
```typescript
|
|
// auth-client.ts (connaît Supabase, rien d'autre)
|
|
export async function getAccessToken(): Promise<string | null> { ... }
|
|
|
|
// api-client.ts (connaît HTTP, rien d'autre)
|
|
export async function apiFetch<T>(path: string, options: RequestOptions = {}): Promise<T> {
|
|
const token = options.token ?? await getAccessToken()
|
|
// fetch avec Bearer token
|
|
}
|
|
```
|
|
|
|
- Avantages : séparation des responsabilités claire (auth vs HTTP), chaque fichier testable indépendamment, migration d'auth = modifier un seul fichier, respecte le principe d'inversion de dépendance.
|
|
- Inconvénients : deux fichiers au lieu d'un (impact négligeable).
|
|
|
|
## Décision
|
|
|
|
**Option B** — deux fichiers séparés :
|
|
|
|
- `src/shared/lib/auth-client.ts` : gère exclusivement Supabase Auth (login, logout, register, récupération du token, refresh de session).
|
|
- `src/shared/lib/api-client.ts` : gère exclusivement les appels HTTP vers `api.expria.app` (fetch, retry, timeout, logging, parsing d'erreurs).
|
|
|
|
L'api-client appelle `getAccessToken()` depuis l'auth-client, mais n'importe aucun type ni fonction Supabase directement.
|
|
|
|
## Conséquences
|
|
|
|
**Positives :**
|
|
- Un dev qui arrive comprend en 30 secondes : "ici l'auth, ici l'HTTP".
|
|
- Le test de `api-client.ts` ne nécessite pas de mocker Supabase — on injecte un token factice.
|
|
- Si Supabase est remplacé un jour (peu probable mais possible), seul `auth-client.ts` change. Aucun fichier feature n'est touché.
|
|
- Cohérent avec la Règle 1 de `DEVELOPMENT_PRINCIPLES.md` : séparation stricte des responsabilités.
|
|
|
|
**Négatives :**
|
|
- Un fichier supplémentaire. Coût négligeable.
|
|
|
|
**À revisiter si :**
|
|
- Un besoin de couplage fort émerge (ex : un token custom généré par le backend plutôt que Supabase). Dans ce cas, la séparation reste valide — on change juste l'implémentation interne de `getAccessToken()`.
|
|
|
|
## Références
|
|
|
|
- `DEVELOPMENT_PRINCIPLES.md` Règle 1 (séparation stricte)
|
|
- `ARCHITECTURE.md` §10 Règle 1 (le frontend ne contient aucune logique métier)
|