# Événements de cycle de vie { #lifespan-events }

Vous pouvez définir une logique (du code) qui doit être exécutée avant que l'application ne **démarre**. Cela signifie que ce code sera exécuté **une seule fois**, **avant** que l'application ne **commence à recevoir des requêtes**.

# Personnaliser les classes Request et APIRoute { #custom-request-and-apiroute-class }

Dans certains cas, vous pouvez vouloir surcharger la logique utilisée par les classes `Request` et `APIRoute`.

En particulier, cela peut être une bonne alternative à une logique dans un middleware.

Par exemple, si vous voulez lire ou manipuler le corps de la requête avant qu'il ne soit traité par votre application.

/// danger | Danger

Et vos utilisateurs définissent aussi, d'une manière ou d'une autre (par exemple dans un tableau de bord Web), l'URL à laquelle votre application doit envoyer ces requêtes.

Toute la logique de gestion des URL des webhooks et le code qui envoie effectivement ces requêtes vous incombent. Vous l'implémentez comme vous le souhaitez dans votre propre code.

Ensuite, ce système (dans ce cas **FastAPI**) se charge de faire tout le nécessaire pour fournir à votre code ces dépendances requises (« injecter » les dépendances).

C’est très utile lorsque vous avez besoin de :

* Avoir de la logique partagée (la même logique de code encore et encore).
* Partager des connexions à la base de données.
* Imposer la sécurité, l’authentification, des exigences de rôles, etc.
* Et bien d’autres choses ...

{* ../../docs_src/websockets_/tutorial002_an_py310.py hl[68:69,82] *}

/// info

Comme il s'agit d'un WebSocket, il n'est pas vraiment logique de lever une `HTTPException`, nous levons plutôt une `WebSocketException`.

Vous pouvez utiliser un code de fermeture parmi les [codes valides définis dans la spécification](https://tools.ietf.org/html/rfc6455#section-7.4.1).

Concentrons‑nous donc sur les cas principaux, où elle pourrait planter entièrement dans certaines situations particulières **à l'avenir**, et où il est toujours logique de la redémarrer.

///

### Conclusion sur les burgers { #burger-conclusion }

Dans ce scénario des « burgers du fast-food avec votre crush », comme il y a beaucoup d'attente 🕙, il est très logique d'avoir un système concurrent ⏸🔀⏯.

Et c'est le cas pour la plupart des applications web.

Vous aurez de nombreux, nombreux utilisateurs, mais votre serveur attendra 🕙 que leur connexion peu performante envoie des requêtes.

Cela a été modifié dans FastAPI 0.106.0 afin de ne pas conserver des ressources pendant l’attente de la transmission de la réponse sur le réseau.

/// tip | Astuce

De plus, une tâche d’arrière‑plan est normalement un ensemble de logique indépendant qui devrait être géré séparément, avec ses propres ressources (par ex. sa propre connexion à la base de données).

Ainsi, vous aurez probablement un code plus propre.

///

Voyons maintenant le module `app/main.py`.

C'est ici que vous importez et utilisez la classe `FastAPI`.

Ce sera le fichier principal de votre application qui reliera tout ensemble.

Et comme la plupart de votre logique vivra désormais dans son propre module, le fichier principal sera assez simple.

### Importer `FastAPI` { #import-fastapi }

Vous importez et créez une classe `FastAPI` comme d'habitude.

Comme nous déclarons maintenant ces scopes, ils apparaîtront dans la documentation de l’API lorsque vous vous authentifiez/autorisez.

Et vous pourrez sélectionner à quels scopes vous souhaitez accorder l’accès : `me` et `items`.

C’est le même mécanisme utilisé lorsque vous donnez des permissions en vous connectant avec Facebook, Google, GitHub, etc. :

<img src="/img/tutorial/security/image11.png">