Browse Source
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>pull/14830/head
Sebastián Ramírez
4 months ago
committed by
GitHub
GitHub
24 changed files with 2279 additions and 1278 deletions
@ -1,34 +1,34 @@ |
|||
# Test de performance |
|||
# Tests de performance { #benchmarks } |
|||
|
|||
Les tests de performance de TechEmpower montrent que les applications **FastAPI** tournant sous Uvicorn comme <a href="https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l=zijzen-7" class="external-link" target="_blank">étant l'un des frameworks Python les plus rapides disponibles</a>, seulement inférieur à Starlette et Uvicorn (tous deux utilisés au cœur de FastAPI). (*) |
|||
Les benchmarks indépendants de TechEmpower montrent que les applications **FastAPI** s’exécutant avec Uvicorn sont <a href="https://www.techempower.com/benchmarks/#section=test&runid=7464e520-0dc2-473d-bd34-dbdfd7e85911&hw=ph&test=query&l=zijzen-7" class="external-link" target="_blank">parmi les frameworks Python les plus rapides disponibles</a>, seulement en dessous de Starlette et Uvicorn eux‑mêmes (tous deux utilisés en interne par FastAPI). |
|||
|
|||
Mais en prêtant attention aux tests de performance et aux comparaisons, il faut tenir compte de ce qu'il suit. |
|||
Mais en prêtant attention aux tests de performance et aux comparaisons, vous devez tenir compte de ce qui suit. |
|||
|
|||
## Tests de performance et rapidité |
|||
## Tests de performance et rapidité { #benchmarks-and-speed } |
|||
|
|||
Lorsque vous vérifiez les tests de performance, il est commun de voir plusieurs outils de différents types comparés comme équivalents. |
|||
|
|||
En particulier, on voit Uvicorn, Starlette et FastAPI comparés (parmi de nombreux autres outils). |
|||
|
|||
Plus le problème résolu par un outil est simple, mieux seront les performances obtenues. Et la plupart des tests de performance ne prennent pas en compte les fonctionnalités additionnelles fournies par les outils. |
|||
Plus le problème résolu par un outil est simple, meilleures seront les performances obtenues. Et la plupart des tests de performance ne prennent pas en compte les fonctionnalités additionnelles fournies par les outils. |
|||
|
|||
La hiérarchie est la suivante : |
|||
|
|||
* **Uvicorn** : un serveur ASGI |
|||
* **Starlette** : (utilise Uvicorn) un micro-framework web |
|||
* **FastAPI**: (utilise Starlette) un micro-framework pour API disposant de fonctionnalités additionnelles pour la création d'API, avec la validation des données, etc. |
|||
* **Starlette** : (utilise Uvicorn) un microframework web |
|||
* **FastAPI**: (utilise Starlette) un microframework pour API disposant de fonctionnalités additionnelles pour la création d'API, avec la validation des données, etc. |
|||
|
|||
* **Uvicorn** : |
|||
* A les meilleures performances, étant donné qu'il n'a pas beaucoup de code mis-à-part le serveur en lui-même. |
|||
* On n'écrit pas une application avec uniquement Uvicorn. Cela signifie que le code devrait inclure plus ou moins, au minimum, tout le code offert par Starlette (ou **FastAPI**). Et si on fait cela, l'application finale apportera les mêmes complications que si on avait utilisé un framework et que l'on avait minimisé la quantité de code et de bugs. |
|||
* Si on compare Uvicorn, il faut le comparer à d'autre applications de serveurs comme Daphne, Hypercorn, uWSGI, etc. |
|||
* A les meilleures performances, étant donné qu'il n'a pas beaucoup de code mis à part le serveur en lui‑même. |
|||
* On n'écrit pas une application directement avec Uvicorn. Cela signifie que le code devrait inclure, au minimum, plus ou moins tout le code offert par Starlette (ou **FastAPI**). Et si on fait cela, l'application finale aura la même surcharge que si on avait utilisé un framework, tout en minimisant la quantité de code et les bugs. |
|||
* Si on compare Uvicorn, il faut le comparer à d'autres serveurs d'applications comme Daphne, Hypercorn, uWSGI, etc. |
|||
* **Starlette** : |
|||
* A les seconde meilleures performances après Uvicorn. Starlette utilise en réalité Uvicorn. De ce fait, il ne peut qu’être plus "lent" qu'Uvicorn car il requiert l'exécution de plus de code. |
|||
* Cependant il nous apporte les outils pour construire une application web simple, avec un routage basé sur des chemins, etc. |
|||
* Si on compare Starlette, il faut le comparer à d'autres frameworks web (ou micorframework) comme Sanic, Flask, Django, etc. |
|||
* A les secondes meilleures performances après Uvicorn. En réalité, Starlette utilise Uvicorn. De ce fait, il ne peut qu’être plus « lent » qu'Uvicorn car il requiert l'exécution de plus de code. |
|||
* Cependant, il apporte les outils pour construire une application web simple, avec un routage basé sur des chemins, etc. |
|||
* Si on compare Starlette, il faut le comparer à d'autres frameworks web (ou microframeworks) comme Sanic, Flask, Django, etc. |
|||
* **FastAPI** : |
|||
* Comme Starlette, FastAPI utilise Uvicorn et ne peut donc pas être plus rapide que ce dernier. |
|||
* FastAPI apporte des fonctionnalités supplémentaires à Starlette. Des fonctionnalités qui sont nécessaires presque systématiquement lors de la création d'une API, comme la validation des données, la sérialisation. En utilisant FastAPI, on obtient une documentation automatiquement (qui ne requiert aucune manipulation pour être mise en place). |
|||
* Si on n'utilisait pas FastAPI mais directement Starlette (ou un outil équivalent comme Sanic, Flask, Responder, etc) il faudrait implémenter la validation des données et la sérialisation par nous-même. Le résultat serait donc le même dans les deux cas mais du travail supplémentaire serait à réaliser avec Starlette, surtout en considérant que la validation des données et la sérialisation représentent la plus grande quantité de code à écrire dans une application. |
|||
* De ce fait, en utilisant FastAPI on minimise le temps de développement, les bugs, le nombre de lignes de code, et on obtient les mêmes performances (si ce n'est de meilleurs performances) que l'on aurait pu avoir sans ce framework (en ayant à implémenter de nombreuses fonctionnalités importantes par nous-mêmes). |
|||
* Si on compare FastAPI, il faut le comparer à d'autres frameworks web (ou ensemble d'outils) qui fournissent la validation des données, la sérialisation et la documentation, comme Flask-apispec, NestJS, Molten, etc. |
|||
* Comme Starlette utilise Uvicorn et ne peut donc pas être plus rapide que lui, **FastAPI** utilise Starlette et ne peut donc pas être plus rapide que lui. |
|||
* FastAPI apporte des fonctionnalités supplémentaires à Starlette. Des fonctionnalités dont vous avez presque toujours besoin lors de la création d'une API, comme la validation des données et la sérialisation. En l'utilisant, vous obtenez une documentation automatique « gratuitement » (la documentation automatique n'ajoute même pas de surcharge à l’exécution, elle est générée au démarrage). |
|||
* Si on n'utilisait pas FastAPI mais directement Starlette (ou un autre outil comme Sanic, Flask, Responder, etc.), il faudrait implémenter toute la validation des données et la sérialisation soi‑même. L'application finale aurait donc la même surcharge que si elle avait été construite avec FastAPI. Et dans de nombreux cas, cette validation des données et cette sérialisation représentent la plus grande quantité de code écrite dans les applications. |
|||
* De ce fait, en utilisant FastAPI on minimise le temps de développement, les bugs, le nombre de lignes de code, et on obtient probablement les mêmes performances (voire de meilleures performances) que l'on aurait pu avoir sans ce framework (car il aurait fallu tout implémenter dans votre code). |
|||
* Si on compare FastAPI, il faut le comparer à d'autres frameworks d’application web (ou ensembles d'outils) qui fournissent la validation des données, la sérialisation et la documentation, comme Flask-apispec, NestJS, Molten, etc. Des frameworks avec validation des données, sérialisation et documentation automatiques intégrées. |
|||
|
|||
@ -1,56 +1,231 @@ |
|||
# À propos de HTTPS |
|||
# À propos de HTTPS { #about-https } |
|||
|
|||
Il est facile de penser que HTTPS peut simplement être "activé" ou non. |
|||
Il est facile de supposer que HTTPS est quelque chose qui est simplement « activé » ou non. |
|||
|
|||
Mais c'est beaucoup plus complexe que cela. |
|||
|
|||
/// tip |
|||
/// tip | Astuce |
|||
|
|||
Si vous êtes pressé ou si cela ne vous intéresse pas, passez aux sections suivantes pour obtenir des instructions étape par étape afin de tout configurer avec différentes techniques. |
|||
Si vous êtes pressé ou si cela ne vous intéresse pas, continuez avec les sections suivantes pour obtenir des instructions étape par étape afin de tout configurer avec différentes techniques. |
|||
|
|||
/// |
|||
|
|||
Pour apprendre les bases du HTTPS, du point de vue d'un utilisateur, consultez <a href="https://howhttps.works/" |
|||
class="external-link" target="_blank">https://howhttps.works/</a>. |
|||
Pour apprendre les bases du HTTPS, du point de vue d'un utilisateur, consultez <a href="https://howhttps.works/" class="external-link" target="_blank">https://howhttps.works/</a>. |
|||
|
|||
Maintenant, du point de vue d'un développeur, voici plusieurs choses à avoir en tête en pensant au HTTPS : |
|||
|
|||
* Pour le HTTPS, le serveur a besoin de "certificats" générés par une tierce partie. |
|||
* Ces certificats sont en fait acquis auprès de la tierce partie, et non "générés". |
|||
* Les certificats ont une durée de vie. |
|||
* Ils expirent. |
|||
* Puis ils doivent être renouvelés et acquis à nouveau auprès de la tierce partie. |
|||
* Le cryptage de la connexion se fait au niveau du protocole TCP. |
|||
* C'est une couche en dessous de HTTP. |
|||
* Donc, le certificat et le traitement du cryptage sont faits avant HTTP. |
|||
* TCP ne connaît pas les "domaines", seulement les adresses IP. |
|||
* L'information sur le domaine spécifique demandé se trouve dans les données HTTP. |
|||
* Les certificats HTTPS "certifient" un certain domaine, mais le protocole et le cryptage se font au niveau TCP, avant de savoir quel domaine est traité. |
|||
* Par défaut, cela signifie que vous ne pouvez avoir qu'un seul certificat HTTPS par adresse IP. |
|||
* Quelle que soit la taille de votre serveur ou la taille de chacune des applications qu'il contient. |
|||
* Il existe cependant une solution à ce problème. |
|||
* Il existe une extension du protocole TLS (celui qui gère le cryptage au niveau TCP, avant HTTP) appelée <a |
|||
href="https://fr.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr |
|||
title="Server Name Indication (indication du nom du serveur)">SNI (indication du nom du serveur)</abbr></a>. |
|||
* Cette extension SNI permet à un seul serveur (avec une seule adresse IP) d'avoir plusieurs certificats HTTPS et de servir plusieurs domaines/applications HTTPS. |
|||
* Pour que cela fonctionne, un seul composant (programme) fonctionnant sur le serveur, écoutant sur l'adresse IP publique, doit avoir tous les certificats HTTPS du serveur. |
|||
* Après avoir obtenu une connexion sécurisée, le protocole de communication est toujours HTTP. |
|||
* Le contenu est crypté, même s'il est envoyé avec le protocole HTTP. |
|||
|
|||
Il est courant d'avoir un seul programme/serveur HTTP fonctionnant sur le serveur (la machine, l'hôte, etc.) et |
|||
gérant toutes les parties HTTPS : envoyer les requêtes HTTP décryptées à l'application HTTP réelle fonctionnant sur |
|||
le même serveur (dans ce cas, l'application **FastAPI**), prendre la réponse HTTP de l'application, la crypter en utilisant le certificat approprié et la renvoyer au client en utilisant HTTPS. Ce serveur est souvent appelé un <a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">Proxy de terminaison TLS</a>. |
|||
|
|||
## Let's Encrypt |
|||
|
|||
Avant Let's Encrypt, ces certificats HTTPS étaient vendus par des tiers de confiance. |
|||
|
|||
Le processus d'acquisition d'un de ces certificats était auparavant lourd, nécessitait pas mal de paperasses et les certificats étaient assez chers. |
|||
|
|||
Mais ensuite, <a href="https://letsencrypt.org/" class="external-link" target="_blank">Let's Encrypt</a> a été créé. |
|||
|
|||
Il s'agit d'un projet de la Fondation Linux. Il fournit des certificats HTTPS gratuitement. De manière automatisée. Ces certificats utilisent toutes les sécurités cryptographiques standard et ont une durée de vie courte (environ 3 mois), de sorte que la sécurité est en fait meilleure en raison de leur durée de vie réduite. |
|||
* Pour le HTTPS, **le serveur** doit **disposer de « certificats »** générés par une **tierce partie**. |
|||
* Ces certificats sont en réalité **acquis** auprès de la tierce partie, et non « générés ». |
|||
* Les certificats ont une **durée de vie**. |
|||
* Ils **expirent**. |
|||
* Puis ils doivent être **renouvelés**, **acquis à nouveau** auprès de la tierce partie. |
|||
* Le cryptage de la connexion se fait au **niveau TCP**. |
|||
* C'est une couche **en dessous de HTTP**. |
|||
* Donc, la gestion du **certificat et du cryptage** est effectuée **avant HTTP**. |
|||
* **TCP ne connaît pas les « domaines »**. Il ne connaît que les adresses IP. |
|||
* L'information sur le **domaine spécifique** demandé se trouve dans les **données HTTP**. |
|||
* Les **certificats HTTPS** « certifient » un **certain domaine**, mais le protocole et le cryptage se font au niveau TCP, **avant de savoir** quel domaine est traité. |
|||
* **Par défaut**, cela signifie que vous ne pouvez avoir qu'**un seul certificat HTTPS par adresse IP**. |
|||
* Quelle que soit la taille de votre serveur ou la petitesse de chacune des applications qu'il contient. |
|||
* Il existe cependant une **solution** à ce problème. |
|||
* Il existe une **extension** du protocole **TLS** (celui qui gère le cryptage au niveau TCP, avant HTTP) appelée **<a href="https://en.wikipedia.org/wiki/Server_Name_Indication" class="external-link" target="_blank"><abbr title="Server Name Indication - Indication du nom du serveur">SNI</abbr></a>**. |
|||
* Cette extension SNI permet à un seul serveur (avec une **seule adresse IP**) d'avoir **plusieurs certificats HTTPS** et de servir **plusieurs domaines/applications HTTPS**. |
|||
* Pour que cela fonctionne, un **seul** composant (programme) fonctionnant sur le serveur, écoutant sur l'**adresse IP publique**, doit avoir **tous les certificats HTTPS** du serveur. |
|||
* **Après** l'établissement d'une connexion sécurisée, le protocole de communication est **toujours HTTP**. |
|||
* Le contenu est **crypté**, même s'il est envoyé avec le **protocole HTTP**. |
|||
|
|||
Il est courant d'avoir **un seul programme/serveur HTTP** fonctionnant sur le serveur (la machine, l'hôte, etc.) et **gérant toutes les parties HTTPS** : recevoir les **requêtes HTTPS chiffrées**, envoyer les **requêtes HTTP déchiffrées** à l'application HTTP réelle fonctionnant sur le même serveur (l'application **FastAPI**, dans ce cas), prendre la **réponse HTTP** de l'application, la **chiffrer** en utilisant le **certificat HTTPS** approprié et la renvoyer au client en utilisant **HTTPS**. Ce serveur est souvent appelé un **<a href="https://en.wikipedia.org/wiki/TLS_termination_proxy" class="external-link" target="_blank">Proxy de terminaison TLS</a>**. |
|||
|
|||
Parmi les options que vous pourriez utiliser comme Proxy de terminaison TLS : |
|||
|
|||
* Traefik (qui peut également gérer les renouvellements de certificats) |
|||
* Caddy (qui peut également gérer les renouvellements de certificats) |
|||
* Nginx |
|||
* HAProxy |
|||
|
|||
## Let's Encrypt { #lets-encrypt } |
|||
|
|||
Avant Let's Encrypt, ces **certificats HTTPS** étaient vendus par des tiers de confiance. |
|||
|
|||
Le processus d'acquisition de l'un de ces certificats était auparavant lourd, nécessitait pas mal de paperasses et les certificats étaient assez chers. |
|||
|
|||
Mais ensuite, **<a href="https://letsencrypt.org/" class="external-link" target="_blank">Let's Encrypt</a>** a été créé. |
|||
|
|||
Il s'agit d'un projet de la Fondation Linux. Il fournit **des certificats HTTPS gratuitement**, de manière automatisée. Ces certificats utilisent toutes les sécurités cryptographiques standard et ont une durée de vie courte (environ 3 mois), de sorte que la **sécurité est en fait meilleure** en raison de leur durée de vie réduite. |
|||
|
|||
Les domaines sont vérifiés de manière sécurisée et les certificats sont générés automatiquement. Cela permet également d'automatiser le renouvellement de ces certificats. |
|||
|
|||
L'idée est d'automatiser l'acquisition et le renouvellement de ces certificats, afin que vous puissiez disposer d'un HTTPS sécurisé, gratuitement et pour toujours. |
|||
L'idée est d'automatiser l'acquisition et le renouvellement de ces certificats, afin que vous puissiez disposer d'un **HTTPS sécurisé, gratuitement et pour toujours**. |
|||
|
|||
## HTTPS pour les développeurs { #https-for-developers } |
|||
|
|||
Voici un exemple de ce à quoi pourrait ressembler une API HTTPS, étape par étape, en portant principalement attention aux idées importantes pour les développeurs. |
|||
|
|||
### Nom de domaine { #domain-name } |
|||
|
|||
Tout commencerait probablement par le fait que vous **acquériez** un **nom de domaine**. Ensuite, vous le configureriez dans un serveur DNS (possiblement le même que votre fournisseur cloud). |
|||
|
|||
Vous obtiendriez probablement un serveur cloud (une machine virtuelle) ou quelque chose de similaire, et il aurait une adresse IP **publique** <abbr title="Qui ne change pas">fixe</abbr>. |
|||
|
|||
Dans le ou les serveurs DNS, vous configureriez un enregistrement (un « `A record` ») pour faire pointer **votre domaine** vers l'**adresse IP publique de votre serveur**. |
|||
|
|||
Vous feriez probablement cela une seule fois, la première fois, lors de la mise en place de l'ensemble. |
|||
|
|||
/// tip | Astuce |
|||
|
|||
Cette partie relative au nom de domaine intervient bien avant HTTPS, mais comme tout dépend du domaine et de l'adresse IP, il vaut la peine de la mentionner ici. |
|||
|
|||
/// |
|||
|
|||
### DNS { #dns } |
|||
|
|||
Concentrons-nous maintenant sur toutes les parties réellement liées à HTTPS. |
|||
|
|||
D'abord, le navigateur vérifierait auprès des **serveurs DNS** quelle est l'**IP du domaine**, dans ce cas, `someapp.example.com`. |
|||
|
|||
Les serveurs DNS indiqueraient au navigateur d'utiliser une **adresse IP** spécifique. Ce serait l'adresse IP publique utilisée par votre serveur, celle que vous avez configurée dans les serveurs DNS. |
|||
|
|||
<img src="/img/deployment/https/https01.drawio.svg"> |
|||
|
|||
### Début de la négociation TLS (Handshake) { #tls-handshake-start } |
|||
|
|||
Le navigateur communiquerait ensuite avec cette adresse IP sur le **port 443** (le port HTTPS). |
|||
|
|||
La première partie de la communication consiste simplement à établir la connexion entre le client et le serveur et à décider des clés cryptographiques qu'ils utiliseront, etc. |
|||
|
|||
<img src="/img/deployment/https/https02.drawio.svg"> |
|||
|
|||
Cette interaction entre le client et le serveur pour établir la connexion TLS s'appelle la **négociation TLS (TLS handshake)**. |
|||
|
|||
### TLS avec l'extension SNI { #tls-with-sni-extension } |
|||
|
|||
**Un seul processus** sur le serveur peut écouter sur un **port** spécifique d'une **adresse IP** spécifique. Il pourrait y avoir d'autres processus écoutant sur d'autres ports de la même adresse IP, mais un seul pour chaque combinaison d'adresse IP et de port. |
|||
|
|||
TLS (HTTPS) utilise par défaut le port spécifique `443`. C'est donc le port dont nous aurions besoin. |
|||
|
|||
Comme un seul processus peut écouter sur ce port, le processus qui le ferait serait le **Proxy de terminaison TLS**. |
|||
|
|||
Le Proxy de terminaison TLS aurait accès à un ou plusieurs **certificats TLS** (certificats HTTPS). |
|||
|
|||
En utilisant l'**extension SNI** mentionnée plus haut, le Proxy de terminaison TLS vérifierait lequel des certificats TLS (HTTPS) disponibles il devrait utiliser pour cette connexion, en choisissant celui qui correspond au domaine attendu par le client. |
|||
|
|||
Dans ce cas, il utiliserait le certificat pour `someapp.example.com`. |
|||
|
|||
<img src="/img/deployment/https/https03.drawio.svg"> |
|||
|
|||
Le client **fait déjà confiance** à l'entité qui a généré ce certificat TLS (dans ce cas Let's Encrypt, mais nous y reviendrons plus tard), il peut donc **vérifier** que le certificat est valide. |
|||
|
|||
Ensuite, en utilisant le certificat, le client et le Proxy de terminaison TLS **décident comment chiffrer** le reste de la **communication TCP**. Cela termine la partie **négociation TLS**. |
|||
|
|||
Après cela, le client et le serveur disposent d'une **connexion TCP chiffrée**, c'est ce que fournit TLS. Ils peuvent alors utiliser cette connexion pour démarrer la **communication HTTP** proprement dite. |
|||
|
|||
Et c'est ce qu'est **HTTPS** : c'est simplement du **HTTP** à l'intérieur d'une **connexion TLS sécurisée** au lieu d'une connexion TCP pure (non chiffrée). |
|||
|
|||
/// tip | Astuce |
|||
|
|||
Remarquez que le cryptage de la communication se produit au **niveau TCP**, pas au niveau HTTP. |
|||
|
|||
/// |
|||
|
|||
### Requête HTTPS { #https-request } |
|||
|
|||
Maintenant que le client et le serveur (spécifiquement le navigateur et le Proxy de terminaison TLS) ont une **connexion TCP chiffrée**, ils peuvent démarrer la **communication HTTP**. |
|||
|
|||
Ainsi, le client envoie une **requête HTTPS**. Ce n'est qu'une requête HTTP à travers une connexion TLS chiffrée. |
|||
|
|||
<img src="/img/deployment/https/https04.drawio.svg"> |
|||
|
|||
### Déchiffrer la requête { #decrypt-the-request } |
|||
|
|||
Le Proxy de terminaison TLS utiliserait le chiffrement convenu pour **déchiffrer la requête**, et transmettrait la **requête HTTP en clair (déchiffrée)** au processus exécutant l'application (par exemple un processus avec Uvicorn exécutant l'application FastAPI). |
|||
|
|||
<img src="/img/deployment/https/https05.drawio.svg"> |
|||
|
|||
### Réponse HTTP { #http-response } |
|||
|
|||
L'application traiterait la requête et enverrait une **réponse HTTP en clair (non chiffrée)** au Proxy de terminaison TLS. |
|||
|
|||
<img src="/img/deployment/https/https06.drawio.svg"> |
|||
|
|||
### Réponse HTTPS { #https-response } |
|||
|
|||
Le Proxy de terminaison TLS **chiffrerait ensuite la réponse** en utilisant la cryptographie convenue auparavant (qui a commencé avec le certificat pour `someapp.example.com`), et la renverrait au navigateur. |
|||
|
|||
Ensuite, le navigateur vérifierait que la réponse est valide et chiffrée avec la bonne clé cryptographique, etc. Il **déchiffrerait la réponse** et la traiterait. |
|||
|
|||
<img src="/img/deployment/https/https07.drawio.svg"> |
|||
|
|||
Le client (navigateur) saura que la réponse provient du bon serveur parce qu'elle utilise la cryptographie convenue auparavant à l'aide du **certificat HTTPS**. |
|||
|
|||
### Applications multiples { #multiple-applications } |
|||
|
|||
Sur le même serveur (ou les mêmes serveurs), il pourrait y avoir **plusieurs applications**, par exemple d'autres programmes d'API ou une base de données. |
|||
|
|||
Un seul processus peut gérer l'adresse IP et le port spécifiques (le Proxy de terminaison TLS dans notre exemple), mais les autres applications/processus peuvent également s'exécuter sur le ou les serveurs, tant qu'ils n'essaient pas d'utiliser la même **combinaison d'adresse IP publique et de port**. |
|||
|
|||
<img src="/img/deployment/https/https08.drawio.svg"> |
|||
|
|||
De cette façon, le Proxy de terminaison TLS pourrait gérer HTTPS et les certificats pour **plusieurs domaines**, pour plusieurs applications, puis transmettre les requêtes à la bonne application dans chaque cas. |
|||
|
|||
### Renouvellement des certificats { #certificate-renewal } |
|||
|
|||
À un moment donné dans le futur, chaque certificat **expirerait** (environ 3 mois après son acquisition). |
|||
|
|||
Ensuite, il y aurait un autre programme (dans certains cas c'est un autre programme, dans d'autres cas cela pourrait être le même Proxy de terminaison TLS) qui communiquerait avec Let's Encrypt et renouvellerait le ou les certificats. |
|||
|
|||
<img src="/img/deployment/https/https.drawio.svg"> |
|||
|
|||
Les **certificats TLS** sont **associés à un nom de domaine**, pas à une adresse IP. |
|||
|
|||
Ainsi, pour renouveler les certificats, le programme de renouvellement doit **prouver** à l'autorité (Let's Encrypt) qu'il **« possède » et contrôle ce domaine**. |
|||
|
|||
Pour ce faire, et pour s'adapter aux différents besoins des applications, il existe plusieurs façons de procéder. Parmi les plus courantes : |
|||
|
|||
* **Modifier certains enregistrements DNS**. |
|||
* Pour cela, le programme de renouvellement doit prendre en charge les API du fournisseur DNS ; ainsi, selon le fournisseur DNS que vous utilisez, cela peut être ou non une option. |
|||
* **S'exécuter comme un serveur** (au moins pendant le processus d'acquisition du certificat) sur l'adresse IP publique associée au domaine. |
|||
* Comme nous l'avons dit plus haut, un seul processus peut écouter sur une adresse IP et un port spécifiques. |
|||
* C'est l'une des raisons pour lesquelles il est très utile que le même Proxy de terminaison TLS prenne également en charge le processus de renouvellement des certificats. |
|||
* Sinon, vous pourriez avoir à arrêter le Proxy de terminaison TLS momentanément, démarrer le programme de renouvellement pour acquérir les certificats, puis les configurer avec le Proxy de terminaison TLS, et ensuite redémarrer le Proxy de terminaison TLS. Ce n'est pas idéal, car votre/vos application(s) ne seront pas disponibles pendant le temps où le Proxy de terminaison TLS est arrêté. |
|||
|
|||
Tout ce processus de renouvellement, tout en continuant à servir l'application, est l'une des principales raisons pour lesquelles vous voudriez avoir un **système séparé pour gérer HTTPS** avec un Proxy de terminaison TLS, au lieu d'utiliser directement les certificats TLS avec le serveur d'application (par exemple Uvicorn). |
|||
|
|||
## En-têtes Proxy Forwarded { #proxy-forwarded-headers } |
|||
|
|||
Lorsque vous utilisez un proxy pour gérer HTTPS, votre **serveur d'application** (par exemple Uvicorn via FastAPI CLI) ne connaît rien du processus HTTPS, il communique en HTTP en clair avec le **Proxy de terminaison TLS**. |
|||
|
|||
Ce **proxy** définirait normalement certains en-têtes HTTP à la volée avant de transmettre la requête au **serveur d'application**, pour informer le serveur d'application que la requête est **transmise** par le proxy. |
|||
|
|||
/// note | Détails techniques |
|||
|
|||
Les en-têtes du proxy sont : |
|||
|
|||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-For" class="external-link" target="_blank">X-Forwarded-For</a> |
|||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto" class="external-link" target="_blank">X-Forwarded-Proto</a> |
|||
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host" class="external-link" target="_blank">X-Forwarded-Host</a> |
|||
|
|||
/// |
|||
|
|||
Néanmoins, comme le **serveur d'application** ne sait pas qu'il se trouve derrière un **proxy** de confiance, par défaut, il ne ferait pas confiance à ces en-têtes. |
|||
|
|||
Mais vous pouvez configurer le **serveur d'application** pour qu'il fasse confiance aux en-têtes transmis (*forwarded*) envoyés par le **proxy**. Si vous utilisez FastAPI CLI, vous pouvez utiliser l'*option CLI* `--forwarded-allow-ips` pour lui indiquer à partir de quelles IP il doit faire confiance à ces en-têtes transmis. |
|||
|
|||
Par exemple, si le **serveur d'application** ne reçoit des communications que du **proxy** de confiance, vous pouvez définir `--forwarded-allow-ips="*"` pour lui faire faire confiance à toutes les IP entrantes, puisqu'il ne recevra des requêtes que depuis l'IP utilisée par le **proxy**. |
|||
|
|||
De cette façon, l'application sera en mesure de savoir quelle est sa propre URL publique, si elle utilise HTTPS, le domaine, etc. |
|||
|
|||
Cela serait utile, par exemple, pour gérer correctement les redirections. |
|||
|
|||
/// tip | Astuce |
|||
|
|||
Vous pouvez en savoir plus dans la documentation [Derrière un proxy - Activer les en-têtes transmis par le proxy](../advanced/behind-a-proxy.md#enable-proxy-forwarded-headers){.internal-link target=_blank} |
|||
|
|||
/// |
|||
|
|||
## Récapitulatif { #recap } |
|||
|
|||
Disposer de **HTTPS** est très important, et assez **critique** dans la plupart des cas. La majeure partie de l'effort que vous, en tant que développeur, devez fournir autour de HTTPS consiste simplement à **comprendre ces concepts** et leur fonctionnement. |
|||
|
|||
Mais une fois que vous connaissez les informations de base sur **HTTPS pour les développeurs**, vous pouvez facilement combiner et configurer différents outils pour vous aider à tout gérer simplement. |
|||
|
|||
Dans certains des prochains chapitres, je vous montrerai plusieurs exemples concrets de configuration de **HTTPS** pour des applications **FastAPI**. 🔒 |
|||
|
|||
@ -1,101 +1,93 @@ |
|||
# À propos des versions de FastAPI |
|||
# À propos des versions de FastAPI { #about-fastapi-versions } |
|||
|
|||
**FastAPI** est déjà utilisé en production dans de nombreuses applications et systèmes. Et la couverture de test est maintenue à 100 %. Mais son développement est toujours aussi rapide. |
|||
**FastAPI** est déjà utilisé en production dans de nombreuses applications et de nombreux systèmes. Et la couverture de tests est maintenue à 100 %. Mais son développement avance toujours rapidement. |
|||
|
|||
De nouvelles fonctionnalités sont ajoutées fréquemment, des bogues sont corrigés régulièrement et le code est |
|||
amélioré continuellement. |
|||
De nouvelles fonctionnalités sont ajoutées fréquemment, des bogues sont corrigés régulièrement et le code s'améliore continuellement. |
|||
|
|||
C'est pourquoi les versions actuelles sont toujours `0.x.x`, cela reflète que chaque version peut potentiellement |
|||
recevoir des changements non rétrocompatibles. Cela suit les conventions de <a href="https://semver.org/" class="external-link" |
|||
target="_blank">versionnage sémantique</a>. |
|||
C'est pourquoi les versions actuelles sont toujours `0.x.x`, cela reflète que chaque version pourrait potentiellement comporter des changements non rétrocompatibles. Cela suit les conventions de <a href="https://semver.org/" class="external-link" target="_blank">versionnage sémantique</a>. |
|||
|
|||
Vous pouvez créer des applications de production avec **FastAPI** dès maintenant (et vous le faites probablement depuis un certain temps), vous devez juste vous assurer que vous utilisez une version qui fonctionne correctement avec le reste de votre code. |
|||
|
|||
## Épinglez votre version de `fastapi` |
|||
## Épingler votre version de `fastapi` { #pin-your-fastapi-version } |
|||
|
|||
Tout d'abord il faut "épingler" la version de **FastAPI** que vous utilisez à la dernière version dont vous savez |
|||
qu'elle fonctionne correctement pour votre application. |
|||
La première chose que vous devez faire est « épingler » la version de **FastAPI** que vous utilisez à la dernière version spécifique dont vous savez qu’elle fonctionne correctement pour votre application. |
|||
|
|||
Par exemple, disons que vous utilisez la version `0.45.0` dans votre application. |
|||
Par exemple, disons que vous utilisez la version `0.112.0` dans votre application. |
|||
|
|||
Si vous utilisez un fichier `requirements.txt`, vous pouvez spécifier la version avec : |
|||
Si vous utilisez un fichier `requirements.txt`, vous pouvez spécifier la version avec : |
|||
|
|||
```txt |
|||
fastapi==0.45.0 |
|||
fastapi[standard]==0.112.0 |
|||
``` |
|||
|
|||
ce qui signifierait que vous utiliseriez exactement la version `0.45.0`. |
|||
ce qui signifierait que vous utiliseriez exactement la version `0.112.0`. |
|||
|
|||
Ou vous pourriez aussi l'épingler avec : |
|||
Ou vous pourriez aussi l'épingler avec : |
|||
|
|||
```txt |
|||
fastapi>=0.45.0,<0.46.0 |
|||
fastapi[standard]>=0.112.0,<0.113.0 |
|||
``` |
|||
|
|||
cela signifierait que vous utiliseriez les versions `0.45.0` ou supérieures, mais inférieures à `0.46.0`, par exemple, une version `0.45.2` serait toujours acceptée. |
|||
cela signifierait que vous utiliseriez les versions `0.112.0` ou supérieures, mais inférieures à `0.113.0`, par exemple, une version `0.112.2` serait toujours acceptée. |
|||
|
|||
Si vous utilisez un autre outil pour gérer vos installations, comme Poetry, Pipenv, ou autres, ils ont tous un moyen que vous pouvez utiliser pour définir des versions spécifiques pour vos paquets. |
|||
Si vous utilisez un autre outil pour gérer vos installations, comme `uv`, Poetry, Pipenv, ou autres, ils ont tous un moyen que vous pouvez utiliser pour définir des versions spécifiques pour vos paquets. |
|||
|
|||
## Versions disponibles |
|||
## Versions disponibles { #available-versions } |
|||
|
|||
Vous pouvez consulter les versions disponibles (par exemple, pour vérifier quelle est la dernière version en date) dans les [Notes de version](../release-notes.md){.internal-link target=_blank}. |
|||
|
|||
## À propos des versions |
|||
## À propos des versions { #about-versions } |
|||
|
|||
Suivant les conventions de versionnage sémantique, toute version inférieure à `1.0.0` peut potentiellement ajouter |
|||
des changements non rétrocompatibles. |
|||
Suivant les conventions de versionnage sémantique, toute version inférieure à `1.0.0` peut potentiellement ajouter des changements non rétrocompatibles. |
|||
|
|||
FastAPI suit également la convention que tout changement de version "PATCH" est pour des corrections de bogues et |
|||
des changements rétrocompatibles. |
|||
FastAPI suit également la convention selon laquelle tout changement de version « PATCH » concerne des corrections de bogues et des changements rétrocompatibles. |
|||
|
|||
/// tip | Astuce |
|||
|
|||
Le "PATCH" est le dernier chiffre, par exemple, dans `0.2.3`, la version PATCH est `3`. |
|||
Le « PATCH » est le dernier chiffre, par exemple, dans `0.2.3`, la version PATCH est `3`. |
|||
|
|||
/// |
|||
|
|||
Donc, vous devriez être capable d'épingler une version comme suit : |
|||
Donc, vous devriez être en mesure d'épingler une version comme suit : |
|||
|
|||
```txt |
|||
fastapi>=0.45.0,<0.46.0 |
|||
``` |
|||
|
|||
Les changements non rétrocompatibles et les nouvelles fonctionnalités sont ajoutés dans les versions "MINOR". |
|||
Les changements non rétrocompatibles et les nouvelles fonctionnalités sont ajoutés dans les versions « MINOR ». |
|||
|
|||
/// tip | Astuce |
|||
|
|||
Le "MINOR" est le numéro au milieu, par exemple, dans `0.2.3`, la version MINOR est `2`. |
|||
Le « MINOR » est le numéro au milieu, par exemple, dans `0.2.3`, la version MINOR est `2`. |
|||
|
|||
/// |
|||
|
|||
## Mise à jour des versions FastAPI |
|||
## Mettre à niveau les versions de FastAPI { #upgrading-the-fastapi-versions } |
|||
|
|||
Vous devriez tester votre application. |
|||
Vous devez ajouter des tests pour votre application. |
|||
|
|||
Avec **FastAPI** c'est très facile (merci à Starlette), consultez la documentation : [Testing](../tutorial/testing.md){.internal-link target=_blank} |
|||
Avec **FastAPI** c'est très facile (merci à Starlette), consultez les documents : [Tests](../tutorial/testing.md){.internal-link target=_blank} |
|||
|
|||
Après avoir effectué des tests, vous pouvez mettre à jour la version **FastAPI** vers une version plus récente, et vous assurer que tout votre code fonctionne correctement en exécutant vos tests. |
|||
Après avoir des tests, vous pouvez mettre à niveau la version de **FastAPI** vers une version plus récente et vous assurer que tout votre code fonctionne correctement en exécutant vos tests. |
|||
|
|||
Si tout fonctionne, ou après avoir fait les changements nécessaires, et que tous vos tests passent, vous pouvez |
|||
épingler votre version de `fastapi` à cette nouvelle version récente. |
|||
Si tout fonctionne, ou après avoir effectué les changements nécessaires, et que tous vos tests passent, vous pouvez alors épingler votre `fastapi` à cette nouvelle version récente. |
|||
|
|||
## À propos de Starlette |
|||
## À propos de Starlette { #about-starlette } |
|||
|
|||
Vous ne devriez pas épingler la version de `starlette`. |
|||
Vous ne devez pas épingler la version de `starlette`. |
|||
|
|||
Différentes versions de **FastAPI** utiliseront une version spécifique plus récente de Starlette. |
|||
|
|||
Ainsi, vous pouvez simplement laisser **FastAPI** utiliser la bonne version de Starlette. |
|||
|
|||
## À propos de Pydantic |
|||
## À propos de Pydantic { #about-pydantic } |
|||
|
|||
Pydantic inclut des tests pour **FastAPI** avec ses propres tests, ainsi les nouvelles versions de Pydantic (au-dessus |
|||
de `1.0.0`) sont toujours compatibles avec **FastAPI**. |
|||
Pydantic inclut les tests pour **FastAPI** avec ses propres tests, ainsi les nouvelles versions de Pydantic (au-dessus de `1.0.0`) sont toujours compatibles avec FastAPI. |
|||
|
|||
Vous pouvez épingler Pydantic à toute version supérieure à `1.0.0` qui fonctionne pour vous et inférieure à `2.0.0`. |
|||
Vous pouvez épingler Pydantic à toute version supérieure à `1.0.0` qui fonctionne pour vous. |
|||
|
|||
Par exemple : |
|||
Par exemple : |
|||
|
|||
```txt |
|||
pydantic>=1.2.0,<2.0.0 |
|||
pydantic>=2.7.0,<3.0.0 |
|||
``` |
|||
|
|||
@ -1,5 +1,5 @@ |
|||
# Apprendre |
|||
# Apprendre { #learn } |
|||
|
|||
Voici les sections introductives et les tutoriels pour apprendre **FastAPI**. |
|||
|
|||
Vous pouvez considérer ceci comme un **manuel**, un **cours**, la **méthode officielle** et recommandée pour appréhender FastAPI. 😎 |
|||
Vous pouvez considérer ceci comme un **livre**, un **cours**, la **méthode officielle** et recommandée pour apprendre FastAPI. 😎 |
|||
|
|||
@ -1,84 +1,28 @@ |
|||
# Génération de projets - Modèle |
|||
|
|||
Vous pouvez utiliser un générateur de projet pour commencer, qui réalisera pour vous la mise en place de bases côté architecture globale, sécurité, base de données et premières routes d'API. |
|||
|
|||
Un générateur de projet fera toujours une mise en place très subjective que vous devriez modifier et adapter suivant vos besoins, mais cela reste un bon point de départ pour vos projets. |
|||
|
|||
## Full Stack FastAPI PostgreSQL |
|||
|
|||
GitHub : <a href="https://github.com/tiangolo/full-stack-fastapi-postgresql" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-fastapi-postgresql</a> |
|||
|
|||
### Full Stack FastAPI PostgreSQL - Fonctionnalités |
|||
|
|||
* Intégration **Docker** complète (basée sur Docker). |
|||
* Déploiement Docker en mode <a href="https://docs.docker.com/engine/swarm/" class="external-link" target="_blank">Swarm</a> |
|||
* Intégration **Docker Compose** et optimisation pour développement local. |
|||
* Serveur web Python **prêt au déploiement** utilisant Uvicorn et Gunicorn. |
|||
* Backend Python <a href="https://github.com/fastapi/fastapi" class="external-link" target="_blank">**FastAPI**</a> : |
|||
* **Rapide** : Très hautes performances, comparables à **NodeJS** ou **Go** (grâce à Starlette et Pydantic). |
|||
* **Intuitif** : Excellent support des éditeurs. <abbr title="aussi appelée auto-complétion, autocomplétion, IntelliSense...">Complétion</abbr> partout. Moins de temps passé à déboguer. |
|||
* **Facile** : Fait pour être facile à utiliser et apprendre. Moins de temps passé à lire de la documentation. |
|||
* **Concis** : Minimise la duplication de code. Plusieurs fonctionnalités à chaque déclaration de paramètre. |
|||
* **Robuste** : Obtenez du code prêt pour être utilisé en production. Avec de la documentation automatique interactive. |
|||
* **Basé sur des normes** : Basé sur (et totalement compatible avec) les normes ouvertes pour les APIs : <a href="https://github.com/OAI/OpenAPI-Specification" class="external-link" target="_blank">OpenAPI</a> et <a href="https://json-schema.org/" class="external-link" target="_blank">JSON Schema</a>. |
|||
* <a href="https://fastapi.tiangolo.com/features/" class="external-link" target="_blank">**Et bien d'autres fonctionnalités**</a> comme la validation automatique, la sérialisation, l'authentification avec OAuth2 JWT tokens, etc. |
|||
* Hashage de **mots de passe sécurisé** par défaut. |
|||
* Authentification par **jetons JWT**. |
|||
* Modèles **SQLAlchemy** (indépendants des extensions Flask, afin qu'ils puissent être utilisés directement avec des *workers* Celery). |
|||
* Modèle de démarrages basiques pour les utilisateurs (à modifier et supprimer au besoin). |
|||
* Migrations **Alembic**. |
|||
* **CORS** (partage des ressources entre origines multiples, ou *Cross Origin Resource Sharing*). |
|||
* *Worker* **Celery** pouvant importer et utiliser les modèles et le code du reste du backend. |
|||
* Tests du backend REST basés sur **Pytest**, intégrés dans Docker, pour que vous puissiez tester toutes les interactions de l'API indépendamment de la base de données. Étant exécutés dans Docker, les tests peuvent utiliser un nouvel entrepôt de données créé de zéro à chaque fois (vous pouvez donc utiliser ElasticSearch, MongoDB, CouchDB, etc. et juste tester que l'API fonctionne). |
|||
* Intégration Python facile avec **Jupyter Kernels** pour le développement à distance ou intra-Docker avec des extensions comme Atom Hydrogen ou Visual Studio Code Jupyter. |
|||
* Frontend **Vue** : |
|||
* Généré avec Vue CLI. |
|||
* Gestion de l'**Authentification JWT**. |
|||
* Page de connexion. |
|||
* Après la connexion, page de tableau de bord principal. |
|||
* Tableau de bord principal avec création et modification d'utilisateurs. |
|||
* Modification de ses propres caractéristiques utilisateur. |
|||
* **Vuex**. |
|||
* **Vue-router**. |
|||
* **Vuetify** pour de magnifiques composants *material design*. |
|||
* **TypeScript**. |
|||
* Serveur Docker basé sur **Nginx** (configuré pour être facilement manipulé avec Vue-router). |
|||
* Utilisation de *Docker multi-stage building*, pour ne pas avoir besoin de sauvegarder ou *commit* du code compilé. |
|||
* Tests frontend exécutés à la compilation (pouvant être désactivés). |
|||
* Fait aussi modulable que possible, pour pouvoir fonctionner comme tel, tout en pouvant être utilisé qu'en partie grâce à Vue CLI. |
|||
* **PGAdmin** pour les bases de données PostgreSQL, facilement modifiable pour utiliser PHPMYAdmin ou MySQL. |
|||
* **Flower** pour la surveillance de tâches Celery. |
|||
* Équilibrage de charge entre le frontend et le backend avec **Traefik**, afin de pouvoir avoir les deux sur le même domaine, séparés par chemins, mais servis par différents conteneurs. |
|||
* Intégration Traefik, comprenant la génération automatique de certificat **HTTPS** Let's Encrypt. |
|||
* GitLab **CI** (intégration continue), comprenant des tests pour le frontend et le backend. |
|||
|
|||
## Full Stack FastAPI Couchbase |
|||
|
|||
GitHub : <a href="https://github.com/tiangolo/full-stack-fastapi-couchbase" class="external-link" target="_blank">https://github.com/tiangolo/full-stack-fastapi-couchbase</a> |
|||
|
|||
⚠️ **ATTENTION** ⚠️ |
|||
|
|||
Si vous démarrez un nouveau projet de zéro, allez voir les alternatives au début de cette page. |
|||
|
|||
Par exemple, le générateur de projet <a href="https://github.com/tiangolo/full-stack-fastapi-postgresql" class="external-link" target="_blank">Full Stack FastAPI PostgreSQL</a> peut être une meilleure alternative, étant activement maintenu et utilisé et comprenant toutes les nouvelles fonctionnalités et améliorations. |
|||
|
|||
Vous êtes toujours libre d'utiliser le générateur basé sur Couchbase si vous le voulez, cela devrait probablement fonctionner correctement, et si vous avez déjà un projet généré en utilisant ce dernier, cela devrait fonctionner aussi (et vous l'avez déjà probablement mis à jour suivant vos besoins). |
|||
|
|||
Vous pouvez en apprendre plus dans la documentation du dépôt GithHub. |
|||
|
|||
## Full Stack FastAPI MongoDB |
|||
|
|||
...viendra surement plus tard, suivant le temps que j'ai. 😅 🎉 |
|||
|
|||
## Modèles d'apprentissage automatique avec spaCy et FastAPI |
|||
|
|||
GitHub : <a href="https://github.com/microsoft/cookiecutter-spacy-fastapi" class="external-link" target="_blank">https://github.com/microsoft/cookiecutter-spacy-fastapi</a> |
|||
|
|||
## Modèles d'apprentissage automatique avec spaCy et FastAPI - Fonctionnalités |
|||
|
|||
* Intégration d'un modèle NER **spaCy**. |
|||
* Formatage de requête pour **Azure Cognitive Search**. |
|||
* Serveur Python web **prêt à utiliser en production** utilisant Uvicorn et Gunicorn. |
|||
* Déploiement CI/CD Kubernetes pour **Azure DevOps** (AKS). |
|||
* **Multilangues**. Choisissez facilement l'une des langues intégrées à spaCy durant la mise en place du projet. |
|||
* **Facilement généralisable** à d'autres bibliothèques similaires (Pytorch, Tensorflow), et non juste spaCy. |
|||
# Modèle Full Stack FastAPI { #full-stack-fastapi-template } |
|||
|
|||
Les modèles, bien qu'ils soient généralement livrés avec une configuration spécifique, sont conçus pour être flexibles et personnalisables. Cela vous permet de les modifier et de les adapter aux exigences de votre projet, ce qui en fait un excellent point de départ. 🏁 |
|||
|
|||
Vous pouvez utiliser ce modèle pour démarrer, car il inclut une grande partie de la configuration initiale, la sécurité, la base de données et quelques endpoints d'API déjà prêts pour vous. |
|||
|
|||
Dépôt GitHub : <a href="https://github.com/tiangolo/full-stack-fastapi-template" class="external-link" target="_blank">Modèle Full Stack FastAPI</a> |
|||
|
|||
## Modèle Full Stack FastAPI - Pile technologique et fonctionnalités { #full-stack-fastapi-template-technology-stack-and-features } |
|||
|
|||
- ⚡ [**FastAPI**](https://fastapi.tiangolo.com/fr) pour l'API backend Python. |
|||
- 🧰 [SQLModel](https://sqlmodel.tiangolo.com) pour les interactions avec la base de données SQL en Python (ORM). |
|||
- 🔍 [Pydantic](https://docs.pydantic.dev), utilisé par FastAPI, pour la validation des données et la gestion des paramètres. |
|||
- 💾 [PostgreSQL](https://www.postgresql.org) comme base de données SQL. |
|||
- 🚀 [React](https://react.dev) pour le frontend. |
|||
- 💃 Utilisation de TypeScript, des hooks, de Vite et d'autres éléments d'un stack frontend moderne. |
|||
- 🎨 [Tailwind CSS](https://tailwindcss.com) et [shadcn/ui](https://ui.shadcn.com) pour les composants frontend. |
|||
- 🤖 Un client frontend généré automatiquement. |
|||
- 🧪 [Playwright](https://playwright.dev) pour les tests de bout en bout. |
|||
- 🦇 Prise en charge du mode sombre. |
|||
- 🐋 [Docker Compose](https://www.docker.com) pour le développement et la production. |
|||
- 🔒 Hachage sécurisé des mots de passe par défaut. |
|||
- 🔑 Authentification JWT (JSON Web Token). |
|||
- 📫 Récupération de mot de passe par e-mail. |
|||
- ✅ Tests avec [Pytest](https://pytest.org). |
|||
- 📞 [Traefik](https://traefik.io) comme proxy inverse / répartiteur de charge. |
|||
- 🚢 Instructions de déploiement avec Docker Compose, y compris la configuration d'un proxy Traefik frontal pour gérer les certificats HTTPS automatiques. |
|||
- 🏭 CI (intégration continue) et CD (déploiement continu) basés sur GitHub Actions. |
|||
|
|||
Loading…
Reference in new issue