/// tip | Astuce

**GraphQL** résout des cas d'utilisation très spécifiques.

Il présente des **avantages** et des **inconvénients** par rapport aux **API web** classiques.

Assurez-vous d'évaluer si les **bénéfices** pour votre cas d'utilisation compensent les **inconvénients**. 🤓

///

## Bibliothèques GraphQL { #graphql-libraries }

### Gérer les fichiers et async { #files-and-async }

Dans la plupart des cas, les objets de type fichier ne sont pas compatibles avec `async` et `await` par défaut.

Par exemple, ils n'ont pas de `await file.read()`, ni de `async for chunk in file`.

Et dans de nombreux cas, leur lecture serait une opération bloquante (pouvant bloquer la boucle d'événements), car ils sont lus depuis le disque ou le réseau.

Mais dans la plupart des cas où nous avons besoin de quelque chose comme cela, nous voulons que le modèle **filtre/supprime** simplement une partie des données comme dans cet exemple.

Bien sûr, il y a des cas où il n'y a aucun problème à exécuter les étapes préalables plusieurs fois ; dans ce cas, c'est beaucoup plus simple à gérer.

/// tip | Astuce

Gardez aussi à l'esprit que selon votre configuration, dans certains cas vous **n'aurez peut‑être même pas besoin d'étapes préalables** avant de démarrer votre application.

Dans ce cas, vous n'auriez pas à vous soucier de tout cela. 🤷

///

Dans certains cas, vous n'avez pas vraiment besoin de la valeur de retour d'une dépendance dans votre *fonction de chemin d'accès*.

Ou la dépendance ne retourne aucune valeur.

Mais vous avez quand même besoin qu'elle soit exécutée/résolue.

Vous avez probablement déjà lu que vous pouvez définir un [Code d'état de la réponse](../tutorial/response-status-code.md) par défaut.

Mais dans certains cas, vous devez renvoyer un code d'état différent de celui par défaut.

## Cas d'utilisation { #use-case }

Par exemple, imaginez que vous vouliez renvoyer par défaut un code d'état HTTP « OK » `200`.

De cette façon, vous pouvez effectuer la mise à niveau et vous assurer que tout fonctionne toujours comme prévu.

## `bump-pydantic` { #bump-pydantic }

Dans de nombreux cas, lorsque vous utilisez des modèles Pydantic classiques sans personnalisations, vous pourrez automatiser la majeure partie du processus de migration de Pydantic v1 à Pydantic v2.

Il existe des cas où vous pourriez vouloir avoir le **même schéma pour l'entrée et la sortie**.

Le cas d'usage principal est probablement que vous avez déjà du code client/SDKs générés automatiquement et que vous ne souhaitez pas encore mettre à jour tout ce code client/ces SDKs générés automatiquement ; vous le ferez sans doute à un moment donné, mais peut‑être pas tout de suite.

Dans ce cas, elles seront appliquées à tous les *chemins d'accès* de l'application :

{* ../../docs_src/dependencies/tutorial012_an_py310.py hl[17] *}

Et toutes les idées de la section sur [l'ajout de `dependencies` aux *décorateurs de chemin d'accès*](dependencies-in-path-operation-decorators.md) s'appliquent toujours, mais dans ce cas à tous les *chemins d'accès* de l'application.

### Conteneurs avec plusieurs processus et cas particuliers { #containers-with-multiple-processes-and-special-cases }

Bien sûr, il existe des **cas particuliers** où vous pourriez vouloir avoir **un conteneur** avec plusieurs **processus worker Uvicorn** à l'intérieur.