Backend avancé : les sujets qui suivent

Objectifs

À la fin de cette leçon, vous saurez :

• concevoir pagination, filtres et tri côté API ;
• comprendre cache Redis et invalidation ;
• situer queues, WebSocket et object storage.

🔗 Pour vous rafraîchir la mémoire : migrations de schéma · Pool pg et requêtes paramétrées ($1, $2) · CRUD en SQL · anatomie d'une requête HTTP

Pagination : jamais de liste infinie

GET /tasks?page=2&limit=20&tri=created_at&ordre=desc&fait=false

SELECT * FROM tasks
WHERE fait = $1
ORDER BY created_at DESC
LIMIT 21 OFFSET 20;        -- 21 = limit + 1 pour savoir s'il y a une suite

Règles : limit plafonné serveur (jamais 10000), tri explicite (sans ORDER BY, l'ordre n'est pas garanti !), réponse incluant le total ou un simple hasNext. Pour de très gros volumes, pagination par curseur (WHERE id > $dernier) — plus stable qu'OFFSET quand les données bougent.

Cache Redis : payer une fois

Requête fréquente et coûteuse (page d'accueil) :
  1. clé = "accueil:publié:v3"
  2. GET redis → hit ? renvoyer.
  3. miss → PostgreSQL + SET avec TTL

La difficulté réelle n'est pas la lecture mais l'invalidation : quand une leçon est publiée, quelles clés meurent ? Stratégies : TTL court (simple, légèrement périmé), purge ciblée par événement (précis, à maintenir), versionnage de clés (v3 incrémenté à chaque publication — la technique des clés ci-dessus). Règle : ne pas cacher avant d'avoir mesuré (chapitre monitoring).

Queues : déléguer le lent

POST /inscription → valider → INSERT → ENQUEUE email → répondre 201 immédiatement
                                          ↓ (worker)
                                    envoi SMTP asynchrone + retry

Tout ce qui déplore quelques centaines de ms et peut attendre part en queue : emails, génération de PDF, traitement vidéo. Bénéfices : réponse rapide, retries propres, absorption des pics. Coût : visibilité (où en est mon job ?), idempotence obligatoire des workers.

WebSocket et temps réel

HTTP demande/réponse ne convient pas au push serveur→client. WebSocket ouvre une connexion bidirectionnelle persistante : notifications live, chat, curseurs collaboratifs. Coût : connexions tenues à surveiller, reconnexion à gérer, scalabilité multi-instances plus complexe. Beaucoup de besoins « temps réel » se satisfont de polling léger ou SSE — commencer simple.

Uploads et object storage

Votre module assets de Devmind illustre le pattern local : validation magic bytes, taille max, clé générée, distribution par identifiant. À l'échelle, le même port bascule vers du stockage objet (S3/compatible) : fichiers hors serveur, URLs signées temporaires, durabilité gérée. L'interface FileStorage rend cette migration triviale — c'est exactement pourquoi elle a été isolée.

Exercice

1. Ajoutez pagination + filtres à votre API todo (avec plafond serveur).
2. Écrivez le schéma « publication de leçon → quelles clés de cache mourir » ?
3. Classez : envoi de reçu PDF, lecture de profil, notification live — queue, direct, WebSocket ?

Résumé

• Pagination serveur stricte ; tri explicite ; curseur pour le gros volume.
• Cache après mesure, invalidation pensée AVANT.
• Queue pour le lent, WebSocket pour le push réel, objet pour les fichiers.