Así que, la sección:

```Python
    uvicorn.run(app, host="0.0.0.0", port=8000)
```

se ejecutará.

---

Esto no ocurrirá si importas ese módulo (archivo).

Entonces, si tienes otro archivo `importer.py` con:

```Python
from myapp import app

# Algún código adicional
```

Ayuda mucho durante el **desarrollo**, pero **no** deberías usarla en **producción**.

///

## Conceptos de Despliegue { #deployment-concepts }

Estos ejemplos ejecutan el programa del servidor (por ejemplo, Uvicorn), iniciando **un solo proceso**, escuchando en todas las IPs (`0.0.0.0`) en un puerto predefinido (por ejemplo, `80`).

O podrías tener alguna otra forma de comunicarte con el endpoint de WebSocket.

---

Pero para este ejemplo, usaremos un documento HTML muy simple con algo de JavaScript, todo dentro de un string largo.

Esto, por supuesto, no es lo ideal y no lo usarías para producción.

En producción tendrías una de las opciones anteriores.

Pero es la forma más sencilla de enfocarse en el lado del servidor de WebSockets y tener un ejemplo funcional:

```console
// Crea un directorio "Code"
$ mkdir code
// Cambia a ese directorio
$ cd code
```

...y un ejemplo de código Python...

```Python
wont_work()  # Esto no va a funcionar 😱
works(foo="bar")  # Esto funciona 🎉
```

...y eso es todo.

////

//// tab | Información

El código en bloques de código no debe modificarse, con la excepción de los comentarios.

Puedes definir tareas en segundo plano para que se ejecuten *después* de devolver un response.

Esto es útil para operaciones que necesitan ocurrir después de un request, pero para las que el cliente realmente no necesita esperar a que la operación termine antes de recibir el response.

Esto incluye, por ejemplo:

* Notificaciones por email enviadas después de realizar una acción:

Esta herramienta te ayudará a cambiar automáticamente la mayor parte del código que necesita cambiarse.

Después de esto, puedes ejecutar los tests y revisa si todo funciona. Si es así, ya terminaste. 😎

## Pydantic v1 en v2 { #pydantic-v1-in-v2 }

Pydantic v2 incluye todo lo de Pydantic v1 como un submódulo `pydantic.v1`.

### Usa el atributo `app.dependency_overrides` { #use-the-app-dependency-overrides-attribute }

Para estos casos, tu aplicación **FastAPI** tiene un atributo `app.dependency_overrides`, es un simple `dict`.

Esto no es una limitación de **FastAPI**, es parte del protocolo HTTP.

///

## Resumen { #recap }

De esa manera, la sub-aplicación sabrá usar ese prefijo de path para la interfaz de documentación.

Y la sub-aplicación también podría tener sus propias sub-aplicaciones montadas y todo funcionaría correctamente, porque FastAPI maneja todos estos `root_path`s automáticamente.

## Una aplicación con callbacks { #an-app-with-callbacks }

Veamos todo esto con un ejemplo.

Imagina que desarrollas una aplicación que permite crear facturas.

Estas facturas tendrán un `id`, `title` (opcional), `customer` y `total`.