Aller au contenu principal

Advanced FastAPI

Repères utiles
remarque

Cette note ouvre le deuxième grand bloc du wiki. Son rôle est de montrer comment faire évoluer API de base vers une API plus réaliste, plus robuste et plus riche en fonctionnalités.

Introduction​

Cette note sert de carte de lecture pour tout le bloc avancé. API de base a posé le socle : structure du projet, CRUD, base PostgreSQL, schémas, services et validation manuelle. Ici, l'objectif est de montrer comment ce socle évolue quand l'API commence à gérer de vrais utilisateurs, des relations de données, des notifications, des traitements en arrière-plan et, en bonus, un client web.

Comment lire cette section​

Ce bloc n'est pas une collection de sujets indépendants. Il suit une montée en complexité volontaire :

  1. sécuriser l'API,
  2. relier les données au bon utilisateur,
  3. rendre l'application plus robuste,
  4. brancher des services externes,
  5. ajouter l'infrastructure et les extensions de confort.

Autrement dit, chaque note ajoute une brique qui devient naturelle à partir de la précédente.

Base source utilisée pour cette section​

Cette section est préparée à partir du projet :

/Users/enesbarut/dev_docs/Ultimate-Guide-to-FastAPI-and-Backend-Development-main

et plus précisément des dossiers :

  • 11-Register User
  • 12-Login User
  • 13-Logout User
  • 14-SQL Relations
  • 16-Delivery Partner
  • 18-Send Mail
  • 19-Custom Response
  • 20-Email Confirmation
  • 21-Password Reset
  • 22-SMS
  • 23-Review
  • 24-Celery
  • 25-Many to Many
  • 26-Error Handling
  • 27-Middleware
  • 29-pytest
  • 30-API Testing
  • 31-React JS
  • 32-Frontend
  • 33-Docker

Les grands blocs avancés identifiés​

1. Authentification et cycle utilisateur​

Source repérée :

  • 11-Register User
  • 12-Login User
  • 13-Logout User

Première note déjà rédigée pour ce bloc :

Ce bloc couvre la transition entre une API CRUD simple et une API avec vrais utilisateurs.

Éléments déjà confirmés dans les sources :

  • ajout de routes utilisateur / seller
  • logique de token
  • usage de HTTPBearer
  • validation d'access token via une couche de sécurité dédiée

Exemple observé : le fichier 12-Login User/75-security.py montre un AccessTokenBearer basé sur HTTPBearer, avec décodage du token et rejet des accès invalides.

2. Modélisation plus riche et relations SQL​

Source repérée :

  • 14-SQL Relations
  • 16-Delivery Partner
  • 25-Many to Many

Première note déjà rédigée pour ce bloc :

Ce bloc couvre :

  • relations entre entités,
  • foreign keys,
  • Relationship() avec SQLModel,
  • cas many-to-many via table d'association.

Exemples observés :

  • 14-SQL Relations/81-models.py montre une relation Seller -> Shipments
  • 25-Many to Many/131-models.py montre une table d'association Order

3. Notifications et communication utilisateur​

Source repérée :

  • 18-Send Mail
  • 20-Email Confirmation
  • 21-Password Reset
  • 22-SMS

Première note déjà rédigée pour ce bloc :

Ce bloc montre comment une API commence à parler au monde extérieur :

  • envoi d'email,
  • confirmation d'email,
  • reset de mot de passe,
  • envoi de SMS.

Exemple observé : 24-Celery/125-tasks.py montre aussi que les notifications peuvent être déléguées à des tâches asynchrones.

4. Réponses plus riches et UX backend​

Source repérée :

  • 19-Custom Response

Première note déjà rédigée pour ce bloc :

Ce bloc couvre :

  • réponses JSON standard,
  • réponses fichier,
  • redirections,
  • réponses personnalisées,
  • rendu HTML côté FastAPI pour certains cas ciblés.

Exemples observés :

  • 106-app.py montre JSONResponse, FileResponse, RedirectResponse et une UpperResponse custom
  • 105-shipment.py montre un rendu de template via Jinja2Templates

5. Asynchronisme produit et traitements en arrière-plan​

Source repérée :

  • 24-Celery

Première note déjà rédigée pour ce bloc :

Ce bloc couvre l'idée qu'une API ne fait pas toujours tout immédiatement dans le thread de requête.

Exemples observés :

  • 125-tasks.py utilise Celery
  • intégration avec mail, templates et Twilio
  • usage de Redis comme broker / backend

6. Robustesse applicative​

Source repérée :

  • 26-Error Handling
  • 27-Middleware

Première note déjà rédigée pour ce bloc :

Ce bloc couvre :

  • exceptions métier personnalisées,
  • gestionnaires d'erreurs centralisés,
  • middleware HTTP,
  • logging et instrumentation simple.

Exemples observés :

  • 133-exceptions.py et 134-exceptions.py montrent une hiérarchie d'exceptions métier
  • 135-main.py montre un middleware mesurant le temps de requête et journalisant l'appel

7. Tests automatisés​

Source repérée :

  • 29-pytest
  • 30-API Testing

Première note déjà rédigée pour ce bloc :

Ce bloc couvre :

  • fixtures pytest,
  • génération de données de test,
  • httpx.AsyncClient,
  • override de dépendances FastAPI,
  • base SQLite mémoire pour les tests,
  • tests authentifiés.

Exemples observés :

  • 148-conftest.py
  • 149-conftest.py
  • 149-test_shipment.py

8. Frontend consommant l'API​

Source repérée :

  • 31-React JS
  • 32-Frontend

Première note déjà rédigée pour ce bloc :

Ce bloc ne sera pas forcément prioritaire tout de suite, mais il montre comment l'API commence à vivre avec une vraie interface cliente.

9. Packaging et exécution en environnement isolé​

Source repérée :

  • 33-Docker

Ce bloc couvre :

  • Dockerfile,
  • docker compose,
  • services API / Postgres / Redis / Celery.

Exemples observés :

  • 170-Dockerfile
  • 172-compose.yaml
  • 173-compose.yaml

Ordre de lecture actuellement recommandé pour cette section​

Maintenant que le bloc est largement rédigé, l'ordre le plus utile à suivre n'est plus seulement un ordre théorique d'écriture. C'est surtout un ordre de lecture cohérent avec les notes effectivement en place.

Ordre recommandé :

  1. authentification : Authentification avec FastAPI
  2. relations SQL : Relations SQL avec FastAPI
  3. gestion d'erreurs : Gestion d’erreurs avec FastAPI
  4. middleware : Middleware avec FastAPI
  5. tests : Tests avec FastAPI
  6. Docker : Docker avec FastAPI
  7. réponses personnalisées : Réponses personnalisées avec FastAPI
  8. notifications : Notifications et communication utilisateur avec FastAPI
  9. tâches asynchrones avec Celery : Tâches asynchrones avec Celery et FastAPI
  10. frontend / React en bonus : Frontend React consommant l’API FastAPI

Pourquoi cet ordre ? Parce qu'il garde le cœur backend prioritaire :

  • sécurité,
  • données,
  • robustesse,
  • testabilité,
  • packaging et exécution propre,
  • puis seulement les couches bonus ou de finition.

Comment utiliser cette note​

Utilise cette page comme un hub :

  • pour comprendre ce que couvre le bloc Advanced FastAPI,
  • pour identifier le prochain chapitre utile selon ton besoin,
  • pour garder en tête l'ordre recommandé si tu veux suivre le wiki de manière linéaire.

Les sous-chapitres majeurs du bloc sont maintenant rédigés. Cette note n'annonce donc plus des contenus "à venir" : elle sert surtout d'index raisonné.

Lien avec API de base​

La logique de progression est volontairement simple :

Autrement dit, cette section ne remplace pas la base. Elle s'appuie dessus.

Checklist d’orientation​

Avant de quitter cette note, vérifie que tu sais :

  • où commencer si tu sors de API de base
  • quel ordre suivre pour un parcours backend linéaire
  • quels chapitres relèvent surtout de la robustesse
  • quels chapitres couvrent le cycle utilisateur
  • que cette note sert de hub, pas de tutoriel d’implémentation à elle seule

Résumé final​

Advanced FastAPI n’est plus une simple roadmap de travail. Dans cette v1, c’est la note qui organise la montée en puissance depuis le socle vers :

  • l’authentification,
  • les relations SQL,
  • la robustesse,
  • le packaging,
  • les flows utilisateur,
  • l’async,
  • puis le bonus frontend.

Si tu veux suivre le fil le plus simple, commence par Authentification avec FastAPI puis avance selon l’ordre recommandé plus haut.

Pour aller plus loin​