Je vais vous montrer certains des principaux concepts que vous devriez probablement avoir à l'esprit lors du déploiement
d'une application **FastAPI** (bien que la plupart de ces concepts s'appliquent à tout autre type d'application web).

```Python
UserInDB(
    username="john",
    password="secret",
    email="******@****.***",
    full_name=None,
)
```

Or more exactly, using `user_dict` directly, with whatever contents it might have in the future:

```Python
UserInDB(
    username = user_dict["username"],
    password = user_dict["password"],
    email = user_dict["email"],
    full_name = user_dict["full_name"],
)
```

- fastapi-people.md
- Resources:
  - resources/index.md
  - project-generation.md
  - external-links.md
  - newsletter.md
- About:
  - about/index.md
  - alternatives.md
  - history-design-future.md
  - benchmarks.md
- Help:
  - help/index.md
  - help-fastapi.md
  - contributing.md
- release-notes.md
markdown_extensions:
  toc:
    permalink: true
  markdown.extensions.codehilite:

```txt
fastapi>=0.45.0,<0.46.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.

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.

## Versions disponibles

```Dockerfile
FROM tiangolo/uvicorn-gunicorn-fastapi:python3.7

COPY ./app /app/app
```

### Raspberry Pi et autres architectures

Si vous utilisez Docker sur un Raspberry Pi (qui a un processeur ARM) ou toute autre architecture, vous pouvez créer un `Dockerfile` à partir de zéro, basé sur une image de base Python (qui est multi-architecture) et utiliser Uvicorn seul.

Dans ce cas, votre `Dockerfile` pourrait ressembler à ceci :

* Validation de données.
* Annotations d'API et documentation automatique.

Et vous n'avez besoin de le déclarer qu'une fois.

Each section gradually builds on the previous ones, but it's structured to separate topics, so that you can go directly to any specific one to solve your specific API needs.

It is also built to work as a future reference.

So you can come back and see exactly what you need.

## Run the code

All the code blocks can be copied and used directly (they are actually tested Python files).

                # explicit default status_code, and to extract it from them, instead of
                # doing this inspection tricks, that would probably be in the future
                # TODO: probably make status_code a default class attribute for all
                # responses in Starlette
                response_signature = inspect.signature(current_response_class.__init__)

# ~~SQL (Relational) Databases with Peewee~~ (deprecated)

!!! warning "Deprecated"
    This tutorial is deprecated and will be removed in a future version.

!!! warning
    If you are just starting, the tutorial [SQL (Relational) Databases](../tutorial/sql-databases.md){.internal-link target=_blank} that uses SQLAlchemy should be enough.

    Feel free to skip this.

S'il y avait une `query` (paramètre nommé `q`) dans la requête, alors elle sera écrite dans `log.txt` via une tâche d'arrière-plan.

Et ensuite une autre tâche d'arrière-plan (générée dans les paramètres de la *la fonction de chemin*) écrira un message dans `log.txt` comprenant le paramètre de chemin `email`.

## Détails techniques