Actualmente tengo una aplicación web de matraz que usa el servidor web uWSGI que implementa el estándar WSGI y necesito migrar esta aplicación al servidor web uvicorn que implementa el estándar ASGI.
Si elijo usar el servidor web uvicorn de las muchas opciones disponibles, por ejemplo, Hypercorn, Daphne, entonces, ¿qué microframework web (en lugar de matraz) debería elegir entre las opciones disponibles, por ejemplo, Starlette, Quart, Django/Channels para realizar esta migración? ¿suavemente?
La jerarquía es como:
Uvicorn: an ASGI server Starlette: (uses Uvicorn) a web microframework FastAPI: (uses Starlette) an API microframework with several additional features for building APIs, with data validation, etc.
Por lo que he leído hasta ahora,
Quart es un microframework web de Python basado en Asyncio. Su objetivo es proporcionar la forma más fácil de usar asyncio en un contexto web, especialmente con las aplicaciones Flask existentes.
y
FastAPI ha demostrado ser un marco web de Python con uno de los mejores rendimientos, medido por puntos de referencia de terceros, gracias a que se basa en Starlette y cuenta con su tecnología. https://fastapi.tiangolo.com/benchmarks/
Por favor sugiera con el mejor enfoque
No estoy seguro de que haya una respuesta correcta para esto, ya que depende principalmente de opiniones personales.
Personalmente, creo que Quart proporcionaría la migración más sencilla desde una aplicación Flask existente. Esto se debe a que intencionalmente hice que la API de Quart sea la misma que la API de Flask, lo que garantiza que todo lo que ya entiendes sobre las aplicaciones de Flask aún se aplica a las aplicaciones de Quart. Mi esperanza es que esto le permita concentrarse en aprender conceptos asíncronos/en espera en lugar del marco.
Sin embargo, creo que encontrará su respuesta al considerar lo que necesita hacer que está más allá del marco y si existen extensiones para que pueda hacerlo. En comparación con el ecosistema Flask, todos los ecosistemas de los marcos ASGI son más pequeños.
Así que aquí me gustaría agregar algo que he concluido hasta ahora,
FastAPI aprendió de Flask (y varios de sus complementos) varias cosas, incluida su simplicidad. Por ejemplo, la forma de declarar rutas es muy similar. Eso facilita la migración de Flask a FastAPI (algo que veo que hace mucha gente).
Flask es un marco basado en el estándar actual/antiguo para los marcos web de Python: WSGI.
FastAPI se basa en Starlette, que utiliza el estándar más nuevo para marcos web asincrónicos: ASGI.
Starlette sería más comparable a Flask, al ser un "micro-framework" puro. Casi todo lo que puede hacer con Flask, puede hacerlo con Starlette (y también con FastAPI). Sin embargo, Starlette tiene algunas funciones que no están disponibles en Flask (ni en muchos otros marcos WSGI, como Django, al menos por defecto), como WebSockets, tareas en segundo plano y otras.
Como FastAPI se basa en Starlette, hereda todas sus características. Incluyendo WebSockets, compatibilidad con GraphQL, plantillas, etc. Entonces, como mínimo, con FastAPI puede hacer prácticamente todo lo que puede hacer con Flask.
FastAPI también es un micro-framework (quizás un mini-framework, ya que incluye algunas funciones adicionales para las API). Por lo tanto, puede estructurar el proyecto como desee, en muchos casos, incluso puede usar la mayoría de los mismos archivos de un proyecto de Flask (lo he hecho).
Esto se ha explicado en esta increíble publicación: https://www.quora.com/What-are-the-advantages-of-using-FastAPI-over-flask
Además, la imagen de Docker con Uvicorn administrada por Gunicorn para aplicaciones web FastAPI de alto rendimiento en Python 3.7 y 3.6 con ajuste automático de rendimiento se puede usar para una implementación mínima. https://github.com/tiangolo/uvicorn-gunicorn-fastapi-docker
FastAPI no es comparable a Flask. Es comparable a algo como Flask-RESTPlus.
Starlette es una comparación justa con Flask. Starlette está más actualizada con los estándares modernos, similar a Quart, Sanic, Bocadillo, etc.
En cuanto al mejor enfoque... es simplemente difícil migrar una aplicación de un marco a otro.
Me quedaría con Gunicorn de cualquier manera (usando la clase trabajadora de Uvicorn), ya que el autor de FastAPI recomienda hacerlo.