Django Ninja o FastAPI? Què triaria jo per refer el backend d'una app feta amb IA

Gairebé tots els backends en Python escrits per un agent que m'arriben a la taula són FastAPI. No perquè el fundador ho hagi triat: Claude Code i Cursor hi van de cap quan ningú els diu el contrari, i per a un prototip de cap de setmana és un reflex raonable. Després arriben els primers clients, entra un enginyer sènior o se'n contracta un per uns mesos, i el primer que diu és «això ho hauríem de passar a Django». I llavors el fundador m'escriu per preguntar-me qui té raó.

Escric des del seient de qui refà aquests backends. A Conectia portem a producció apps construïdes amb Claude Code, Cursor, Lovable i companyia, i quan el veredicte sobre el backend és refer, Python és el llenguatge en què ho refem més sovint, perquè és el que ha deixat l'agent i el que l'equip sap llegir. He posat els dos frameworks en producció i no tinc cap interès en cap dels dos. El que tinc és un patró: la pregunta pel framework és una pregunta disfressada; la de debò és quins mòduls han fallat primer i què porta cada framework per a exactament aquests mòduls.

Els mòduls que han fallat són els que FastAPI et deixa a tu

FastAPI és Starlette més Pydantic: encaminament, validació de peticions, injecció de dependències i un document OpenAPI de franc. Això és tot, per disseny, i el seu autor mai no ha dit una altra cosa. La resta la tries i la connectes tu: l'ORM (SQLAlchemy 2.0 en la majoria de casos), les migracions (Alembic), l'autenticació, les sessions, els permisos, un admin, les feines en segon pla, l'arnès de tests. Un equip amb experiència ho munta en una setmana i en queda content.

Un agent també ho munta, en minuts, i aquí comença el problema. Quan llegeixo un backend FastAPI fet amb IA, les fallades coincideixen amb els vuit símptomes que ja vaig descriure, i es concentren a les parts que FastAPI no inclou:

• L'autenticació és una dependència get_current_user que descodifica un token i se'l creu; el refresc, la revocació, el restabliment de contrasenya i la verificació de correu existeixen en la mesura que algú els va demanar a l'agent.
• L'aïllament per tenant és un WHERE organization_id = … que l'agent es va recordar d'afegir a gairebé totes les consultes. La que falta és la fuita de dades.
• Les migracions no existeixen, o es van generar un cop i no es van tornar a executar; l'esquema és el que va produir create_all() a la primera arrencada.
• Els permisos són un if user.role == "admin" repartit pels routers.
• L'admin no existeix, de manera que el suport es fa des d'una consola SQL contra producció.

Res d'això és culpa de FastAPI. Són els mòduls que un framework o bé inclou o bé et demana que construeixis, i un agent que els construeix des de zero produeix una cosa que sembla acabada i no ho és.

Django porta els mòduls que s'han trencat, i Ninja treu el motiu pel qual la gent l'evitava

Django Ninja és una capa d'API prima sobre Django que agafa el tipatge i la validació de Pydantic. El codi de peticions i respostes s'assembla al de FastAPI: anotacions de tipus, esquemes, OpenAPI automàtic, vistes asíncrones si les vols. A sota hi tens Django, i això vol dir que el que l'agent va improvisar ara ve d'un framework amb vint anys de producció a l'esquena: l'ORM, migracions que formen part del flux de treball i no d'una ocurrència posterior, django.contrib.auth amb hash de contrasenyes, sessions i comprovacions de permisos auditades durant dues dècades, l'admin, les ordres de gestió i un runner de tests que entén de transaccions i fixtures. Django 5.2 és una versió de suport estès, amb manteniment fins a l'abril de 2028, que és una frase que a un departament de compres li agrada llegir.

Per als mòduls que s'han trencat, aquesta és la diferència entre escriure i configurar. L'autenticació passa a ser la tria d'un backend i un bloc de settings. L'aïllament per tenant passa a ser un manager de model que filtra per organització i un middleware que la fixa, amb un test que comprova que tots els models porten el camp. Els permisos passen a ser declaracions. L'admin existeix el mateix dia que existeixen els models, i el suport deixa de tocar producció a mà. El motiu pel qual s'evitava Django per a productes d'API era la cerimònia dels serializers de Django REST Framework; Ninja la treu i conserva la resta.

Reconec el contraargument que té fonament. La història asíncrona de Django està a mitges: aget, asave i companyia existeixen, però la capa de base de dades continua passant la consulta a un driver síncron en un fil. Si el teu backend són dotze endpoints que criden un model, emeten tokens per SSE i mantenen websockets oberts, el pes de Django no t'aporta res i el bucle d'esdeveniments de FastAPI t'aporta molt. I si el codi FastAPI que va escriure l'agent funciona, no guarda dades de clients i no té un segon tenant, reescriure'l per una qüestió de marca és el mateix error que la reescriptura contra la qual argumento a el primer post d'aquesta sèrie. La tria del framework va després del veredicte, mai per davant.

La decisió cap en una taula

Aquesta és la regla que aplico quan el veredicte sobre el mòdul de backend diu refer.

La tercera fila és on acabo més sovint. La capa d'IA que l'agent va escriure en FastAPI sol ser la millor part del codi, perquè és sobre el que el fundador va iterar; el nucli de negoci que l'envolta és el que ningú no va llegir. Conservar la primera i refer el segon sobre Django Ninja costa menys que qualsevol dels dos extrems, i encaixa amb el que recomano per a monòlits i serveis en fase d'MVP: un desplegable per cada motiu, no per cada moda.

Refer en l'ordre que manté el producte en marxa

La reconstrucció que funciona no és un univers paral·lel on un backend nou apareix al cap de tres mesos i es canvia d'un dia per l'altre. És una seqüència, i la seqüència comença pel que no canviarà.

1. La base de dades es queda. Postgres és l'actiu. Apunta Django a l'esquema existent, genera els models amb inspectdb i després neteja'ls a mà fins que diguin el que el negoci vol dir. La primera migració és la que deixa constància del que ja existeix.
2. Migracions sota control de versions des del primer dia. A partir d'aquí, cada canvi d'esquema és un fitxer al repositori que la CI aplica sobre una base de dades de staging abans que ningú desplegui. Aquest sol hàbit elimina el símptoma dos, la base de dades que cada setmana va més lenta, perquè un índex passa a ser un canvi revisat.
3. Autenticació i aïllament per tenant abans que cap endpoint. Tria la font d'autenticació (la pròpia de Django, o el proveïdor extern que l'app ja fa servir, verificat a la vora), escriu el manager d'organització i el middleware, i escriu el test que falla quan un model s'oblida del camp de tenant. No es porta res més fins que aquest test està en verd.
4. Congela el contracte amb l'API antiga. FastAPI i Ninja emeten OpenAPI tots dos. Guarda una instantània del document de l'agent i fes que cada endpoint portat passi un test de contracte contra ella. El frontend ni s'assabenta que el backend ha canviat.
5. Porta per mòduls, en l'ordre del go/no-go. Primer els pagaments i tot el que toqui dades personals, perquè és on hi ha el risc; al final els informes i l'accessori. Cada mòdul es mou darrere d'una ruta al gateway, de manera que els dos backends conviuen durant setmanes.
6. Dona a la capa d'IA el seu conjunt d'avaluació. Tant si es queda a FastAPI com si es mou, les funcions basades en model reben un conjunt d'avaluació i una mètrica abans de canviar. Aquesta suite és el que fa segur el següent retoc de prompt.
7. CI, staging i un rollback assajat. Desplega el nucli nou a staging a cada merge, executa els tests de contracte i les avaluacions, i només llavors mou trànsit de producció mòdul a mòdul. El rollback és un canvi de ruta, no una restauració.

Per a un producte en fase seed amb uns quants milers d'usuaris, això són de vuit a deu setmanes d'un enginyer de backend sènior amb un arquitecte que revisa el disseny unes hores a la setmana. Més que un cap de setmana, força menys que el trimestre que costa una reescriptura des de zero, i el producte continua traient funcionalitats tota l'estona.

Què faria jo aquest mes si el backend fos meu

1. Llegeix el veredicte abans que el framework. Si ningú no ha posat nom als mòduls que han fallat, amb la mesura al costat de cadascun, aquesta és la feina de dues setmanes que va primer. Un debat de frameworks sense veredicte és una qüestió de gustos.
2. Fes la llista del que l'agent va improvisar. Autenticació, aïllament per tenant, migracions, permisos, admin, feines en segon pla. Per a cadascun, anota si existeix, si està provat i si algun framework el porta de sèrie.
3. Decideix amb la taula de dalt i deixa la decisió per escrit amb el motiu, perquè el següent enginyer no la reobri.
4. Conserva l'esquema de Postgres i el document OpenAPI com els dos punts fixos. Tota la resta es pot moure; aquests dos són el contracte amb les teves dades i amb el teu frontend.
5. Escriu el CLAUDE.md o l'AGENTS.md abans del primer endpoint portat. El manager de tenant, la prohibició d'SQL en cru, el flux de migracions, l'ordre de tests. L'agent que va escriure la versió u n'escriurà parts de la versió dos, i construeix dins de les convencions que pot llegir.
6. Posa una segona persona a revisar autenticació i aïllament per tenant. En aquests dos mòduls la reconstrucció o bé es paga sola o bé repeteix l'error original amb millors anotacions de tipus.

El framework és la resposta a una pregunta que cal fer abans

«Django Ninja o FastAPI?» és una bona pregunta amb una resposta curta tan bon punt saps quins mòduls han fallat i què deu el teu producte al seu segon client. Fes-la abans del veredicte i tindràs una guerra de religió; fes-la després i la taula de dalt la tanca en una reunió.

Aquest veredicte és el primer pas de com portem a producció una app feta amb IA, i quan el backend s'ha de refer, és l'ordre de dalt, executat amb nosaltres, amb la teva pròpia contractació o amb l'agent que va escriure la primera versió. Si vols la foto d'abans, vaig deixar per escrit què es trenca primer en un MVP fet amb IA i en què es diferencia una app de Lovable sobre Supabase, on la pregunta del backend té una altra forma.