Luego podemos probar que se está usando.

## Leer un archivo `.env` { #reading-a-env-file }

Si tienes muchas configuraciones que posiblemente cambien mucho, tal vez en diferentes entornos, podría ser útil ponerlos en un archivo y luego leerlos desde allí como si fueran variables de entorno.

La palabra "**servidor**" se utiliza comúnmente para referirse tanto al computador remoto/en la nube (la máquina física o virtual) como al programa que se está ejecutando en esa máquina (por ejemplo, Uvicorn).

Solo ten en cuenta que cuando leas "servidor" en general, podría referirse a una de esas dos cosas.

De nuevo, por favor, haz tu mejor esfuerzo por ser amable. 🤗

---

Aquí está lo que debes tener en cuenta y cómo revisar un pull request:

### Entiende el problema { #understand-the-problem }

* Primero, asegúrate de **entender el problema** que el pull request está intentando resolver. Podría tener una discusión más larga en una GitHub Discussion o issue.

También podrías usarlo para generar código automáticamente, para clientes que se comuniquen con tu API. Por ejemplo, aplicaciones frontend, móviles o IoT.

### Configura el `entrypoint` de la app en `pyproject.toml` { #configure-the-app-entrypoint-in-pyproject-toml }

Puedes configurar dónde está tu app en un archivo `pyproject.toml` así:

Y esa función `get_openapi()` recibe como parámetros:

* `title`: El título de OpenAPI, mostrado en la documentación.
* `version`: La versión de tu API, por ejemplo `2.5.0`.
* `openapi_version`: La versión de la especificación OpenAPI utilizada. Por defecto, la más reciente: `3.1.0`.
* `summary`: Un breve resumen de la API.

Por ejemplo, puedes lanzar una excepción diferente, como `HTTPException`.

/// tip | Consejo

Esta es una técnica algo avanzada, y en la mayoría de los casos realmente no la necesitarás, ya que puedes lanzar excepciones (incluyendo `HTTPException`) desde dentro del resto del código de tu aplicación, por ejemplo, en la *path operation function*.

Pero está ahí para ti si la necesitas. 🤓

///

<img src="/img/tutorial/generate-clients/image01.png">

Puedes ver esos esquemas porque fueron declarados con los modelos en la app.

Esa información está disponible en el **OpenAPI schema** de la app, y luego se muestra en la documentación de la API.

Y esa misma información de los modelos que está incluida en OpenAPI es lo que puede usarse para **generar el código del cliente**.

### Hey API { #hey-api }

Por ejemplo, si el **servidor de aplicaciones** solo está recibiendo comunicación del **proxy** de confianza, puedes establecerlo en `--forwarded-allow-ips="*"` para hacer que confíe en todas las IPs entrantes, ya que solo recibirá requests desde la IP que sea utilizada por el **proxy**.

De esta manera la aplicación podrá saber cuál es su propia URL pública, si está usando HTTPS, el dominio, etc.

Se trata solo de palabras y nombres. Pero esas palabras pueden afectar cómo tú y tu equipo piensan sobre el código.

Como ejemplo, tomemos esta función:

```python
from typing import Optional


def say_hi(name: Optional[str]):
    print(f"Hey {name}!")
```

El parámetro `name` está definido como `Optional[str]`, pero **no es opcional**, no puedes llamar a la función sin el parámetro:

```

No está encriptado, por lo que cualquiera podría recuperar la información de los contenidos.

Pero está firmado. Así que, cuando recibes un token que has emitido, puedes verificar que realmente lo emitiste.

De esta manera, puedes crear un token con una expiración de, digamos, 1 semana. Y luego, cuando el usuario regresa al día siguiente con el token, sabes que el usuario todavía está registrado en tu sistema.