Stack: Django + Ninja + Channels

La decisión: Django 6 + django-ninja + channels, con uv y just. Es el mismo stack de seimseim-reservas (el de la casa en Monoku). El frontend es React + Vite.

Por qué no FastAPI

La primera idea fue FastAPI: un proxy delgado sobre Toteat, async, WebSockets nativos. Lo descartamos porque, mirándolo bien, los argumentos no se sostienen frente al stack de la casa:

• django-ninja también es Pydantic primero, o sea la misma comodidad que FastAPI, y encaja natural con los modelos Pydantic de toteat-cli.
• channels resuelve los WebSockets.
• celery-beat es el lugar correcto para las pruebas nocturnas.
• El equipo ya sabe este stack, comparte la identidad de Monoku y puede copiar el CI y el compose. Para un equipo pequeño que opera un restaurante en vivo, eso pesa más que la pequeña ventaja técnica de FastAPI.

Lo que no usamos

Como Toteat es dueño de los datos del negocio, el ORM y el admin de Django sobre un dominio rico no son la ventaja de siempre. Nuestra base de datos solo guarda operadores, roles y auditoría. También dejamos por fuera lo multi-tenant de reservas (django-tenants y el servidor de OAuth): el POS es de un solo local.

El admin

django-unfold le pone tema al admin, igual que en reservas. Los admin propios deben heredar de unfold.admin.ModelAdmin.