Especificamente, observa-se Uvicorn, Starlette e FastAPI comparados juntos (entre muitas outras ferramentas).

Quanto mais simples o problema resolvido pela ferramenta, melhor a performance que ela terá. E a maioria dos _benchmarks_ não testam as características adicionais fornecidas pela ferramenta.

A hierarquia segue assim:

* **Uvicorn**: um servidor ASGI
    * **Starlette**: (utiliza Uvicorn) um _microframework web_

Você também pode usar `url_for()` dentro do template, ele recebe como argumentos os mesmos argumentos que seriam usados pela sua *path operation function*.

Logo, a seção com:

{% raw %}

```jinja
<a href="{{ url_for('read_item', id=id) }}">
```

{% endraw %}

...irá gerar um link para a mesma URL que será tratada pela *path operation function* `read_item(id=id)`.

Por exemplo, com um ID de `42`, isso renderizará:

* Ele pega cada **requisição** que chega ao seu aplicativo.
* Ele pode então fazer algo com essa **requisição** ou executar qualquer código necessário.
* Então ele passa a **requisição** para ser processada pelo resto do aplicativo (por alguma *operação de rota*).
* Ele então pega a **resposta** gerada pelo aplicativo (por alguma *operação de rota*).

{* ../../docs_src/extending_openapi/tutorial001_py39.py hl[13:14,25:26] *}

### Sobrescrever o método { #override-the-method }

Agora, você pode substituir o método `.openapi()` pela sua nova função.

{* ../../docs_src/extending_openapi/tutorial001_py39.py hl[29] *}

### Verificar { #check-it }

{* ../../docs_src/dependencies/tutorial005_an_py310.py hl[13] *}

Vamos focar nos parâmetros declarados:

* Mesmo que essa função seja uma dependência ("dependable") por si mesma, ela também declara uma outra dependência (ela "depende" de outra coisa).
    * Ela depende do `query_extractor`, e atribui o valor retornado pela função ao parâmetro `q`.

* dados do cliente para serem enviados através da rede
* dados enviados pelo seu programa serem recebidos pelo cliente através da rede
* conteúdo de um arquivo no disco ser lido pelo sistema e entregue ao seu programa
* conteúdo que seu programa deu ao sistema para ser escrito no disco
* uma operação em uma API remota
* uma operação no banco de dados finalizar
* uma solicitação no banco de dados retornar o resultado

E então monte isso sob um path.

{* ../../docs_src/wsgi/tutorial001_py39.py hl[2:3,3] *}

## Confira { #check-it }

Agora, todas as requisições sob o path `/v1/` serão manipuladas pela aplicação Flask.

E o resto será manipulado pelo **FastAPI**.

Se você rodar a aplicação e ir até <a href="http://localhost:8000/v1/" class="external-link" target="_blank">http://localhost:8000/v1/</a>, você verá o retorno do Flask:

```txt

Assim, você poderia, por exemplo, compartilhar os mesmos dados de um aplicativo Django em um banco de dados com um aplicativo FastAPI. Ou migrar gradualmente uma aplicação Django usando o mesmo banco de dados.

E seus usuários poderiam fazer login tanto pela sua aplicação Django quanto pela sua aplicação **FastAPI**, ao mesmo tempo.

///

Em alguns casos, você pode querer sobrescrever a lógica usada pelas classes `Request` e `APIRoute`.

Em particular, isso pode ser uma boa alternativa para uma lógica em um middleware.

Por exemplo, se você quiser ler ou manipular o corpo da requisição antes que ele seja processado pela sua aplicação.

/// danger | Cuidado

Isso é um recurso "avançado".

Esses proxies podem lidar com certificados HTTPS e outras coisas.

## Headers Encaminhados pelo Proxy { #proxy-forwarded-headers }

Um **proxy** na frente da sua aplicação normalmente definiria alguns headers dinamicamente antes de enviar as requisições para o seu **servidor**, para informar ao servidor que a requisição foi **encaminhada** pelo proxy, informando a URL original (pública), incluindo o domínio, que está usando HTTPS, etc.