Tengo una aplicación web simple basada en API escrita en Django 3. En la documentación de Django hay una página sobre servidores ASGI y se mencionan dos opciones: Daphne y Uvicorn . Desafortunadamente, no brindan ninguna descripción sobre los beneficios con respecto a una opción en particular, por lo que estoy confundido cuando se trata de seleccionar uno de ellos.
¿Cuáles son, si las hay, las diferencias para escribir una aplicación de Django en torno a los dos y habría algún problema de rendimiento o estabilidad a tener en cuenta?
Básicamente, ¿hay una gran diferencia en usar Uvicorn en lugar de Daphne? Mi servidor se ejecuta en Ubuntu, si eso importa.
Respuesta simple: ya que ha usado gunicorn antes y está familiarizado con él, vaya con uvicorn , especialmente porque debe usarse como trabajador de gunicorn en producción . Si no tiene experiencia con eso, le sugiero a Daphne . Ambos harán el trabajo en un proyecto simple y el rendimiento parece ser igual.
Explicación:
ASGI es una tecnología bastante nueva, al igual que async/await de python en comparación con la mayoría de los otros elementos que cambian el diseño en el lenguaje. Tanto uvicorn , daphne e hypercorn también están en desarrollo activo, por lo que no puede haber ninguna evaluación comparativa "justa" de estas bibliotecas. Entonces, cuando se trata de elegir lo que quieres, en su mayoría tienes que creer en su palabra cuando dicen, por ejemplo; pretenden ser rápidos, fáciles de usar, ligeros o lo que sea.
Dicho todo esto, todavía puedo compartir mi experiencia con Uvicorn y Daphne:
Daphne es definitivamente el proyecto más voluminoso, tiene muchas dependencias que no se usan por completo en todos los proyectos. Seguramente han hecho lo mejor que han podido cubriendo muchas características, y dado que también son parte del equipo de Django, debe esperar una mejor compatibilidad a largo plazo con Django. Sin embargo, comenzar con Daphne puede ser intimidante.
Uvicorn es el más liviano, incluso puedes leer el código de toda la biblioteca y comprender un poco cómo giran los engranajes por dentro. Dado que he usado principalmente Uvicorn, sé que tiene algunas características faltantes y errores que se espera que funcionen de inmediato. Si desea un comportamiento personalizado de su servidor ASGI, manipular Uvicorn es más fácil que la alternativa. Mi parte favorita de Uvicorn es que ni siquiera es un administrador de procesos y está diseñado para trabajar como trabajador de producción de gunicorn.
Nota al margen: conectarse a Uvicorn en realidad no es una intención ni es fácil. En general, no es una buena práctica hacer esto, pero dado que después de 18 horas de buscar una alternativa (personalmente, quería capturar y manejar SIGTERM para un apagado correcto, pero los métodos normales no funcionaron ya que todo está en un bucle asíncrono), No pude encontrar mejores maneras. Así que descaradamente pondré un fragmento de código que le otorgará la escurridiza instancia de "servidor". A partir de ahí, enhebre con cuidado. (sin juego de palabras)
import inspect #Might not be future proof! Use with care from uvicorn import Server as UvicornServer server = next( server for frameinf in inspect.stack() if 'server' in frameinf[0].f_locals and isinstance(server:=frameinf[0].f_locals['server'], UvicornServer) )Otra nota al margen: si realmente elige ir con Uvicorn, y está usando django con canales, es posible que desee eliminar "daphne" primero, ya que es una dependencia de canales bastante poco utilizada .