Historia, Diseño y Futuro¶

Hace algún tiempo, un usuario de FastAPI preguntó:

¿Cuál es la historia de este proyecto? Parece haber salido de la nada a increíble en pocas semanas [...]

Aquí hay un poco de esa historia.

Alternativas¶

He estado creando APIs con requisitos complejos durante varios años (Machine Learning, sistemas distribuidos, trabajos asíncronos, bases de datos NoSQL, etc), liderando varios equipos de desarrolladores.

Como parte de eso, necesité investigar, probar y usar muchas alternativas.

La historia de FastAPI es en gran parte la historia de sus predecesores.

Como se dijo en la sección Alternativas:

FastAPI no existiría si no fuera por el trabajo previo de otros.

Ha habido muchas herramientas creadas antes que han ayudado a inspirar su creación.

He estado evitando la creación de un nuevo framework durante varios años. Primero intenté resolver todas las funcionalidades cubiertas por FastAPI usando muchos frameworks, plug-ins y herramientas diferentes.

Pero en cierto punto, no hubo otra opción más que crear algo que proporcionara todas estas funcionalidades, tomando las mejores ideas de las herramientas anteriores, y combinándolas de la mejor manera posible, usando características del lenguaje que no estaban disponibles antes (Type hints de Python 3.6+).

Investigación¶

Al usar todas las alternativas anteriores tuve la oportunidad de aprender de todas ellas, tomar ideas y combinarlas de la mejor manera que pude encontrar para mí mismo y para los equipos de desarrolladores con los que he trabajado.

Por ejemplo, estaba claro que idealmente debería estar basado en los type hints estándar de Python.

También, el mejor enfoque era usar estándares ya existentes.

Así que, antes de empezar a programar FastAPI, pasé varios meses estudiando las especificaciones de OpenAPI, JSON Schema, OAuth2, etc. Entendiendo sus relaciones, superposiciones y diferencias.

Diseño¶

Luego pasé un tiempo diseñando la "API" de desarrollador que quería tener como usuario (como desarrollador usando FastAPI).

Probé varias ideas en los editores de Python más populares: PyCharm, VS Code, editores basados en Jedi.

Según la última Encuesta de Desarrolladores de Python, eso cubre aproximadamente el 80% de los usuarios.

Significa que FastAPI fue probado específicamente con los editores usados por el 80% de los desarrolladores de Python. Y como la mayoría de los otros editores tienden a funcionar de manera similar, todos sus beneficios deberían funcionar para prácticamente todos los editores.

De esa manera pude encontrar las mejores formas de reducir la duplicación de código lo más posible, tener autocompletado en todas partes, verificación de tipos y errores, etc.

Todo de una manera que proporcionara la mejor experiencia de desarrollo para todos los desarrolladores.

Requisitos¶

Después de probar varias alternativas, decidí que iba a usar Pydantic por sus ventajas.

Luego contribuí a él, para hacerlo totalmente compatible con JSON Schema, para soportar diferentes formas de definir declaraciones de restricciones, y para mejorar el soporte del editor (verificación de tipos, autocompletado) basado en las pruebas en varios editores.

Durante el desarrollo, también contribuí a Starlette, el otro requisito clave.

Desarrollo¶

Para cuando empecé a crear FastAPI propiamente dicho, la mayoría de las piezas ya estaban en su lugar, el diseño estaba definido, los requisitos y herramientas estaban listos, y el conocimiento sobre los estándares y especificaciones era claro y fresco.

Futuro¶

En este punto, ya está claro que FastAPI con sus ideas está siendo útil para mucha gente.

Está siendo elegido sobre las alternativas anteriores por adaptarse mejor a muchos casos de uso.

Muchos desarrolladores y equipos ya dependen de FastAPI para sus proyectos (incluyéndome a mí y a mi equipo).

Pero todavía quedan muchas mejoras y características por venir.

FastAPI tiene un gran futuro por delante.

Y tu ayuda es muy apreciada.