Wer sich mit Python-Backends beschäftigt, landet schnell in der Django-vs-FastAPI-Diskussion. Meistens geht es dabei um Performance. Das war bei uns nicht der Ausschlag.
Unser Betrieb besteht aus vielen kleinen, fokussierten Services: ein Service für SEO-Daten, einer für Content-Generierung, einer für Kunden-Reporting. Diese Services kommunizieren miteinander und mit externen APIs.
Django ist für monolithische Anwendungen gemacht. Gut für Teams, die eine große Codebasis zusammen entwickeln. Für unser Microservice-Setting war es zu viel Struktur für zu wenig Nutzen.
Der eigentliche Grund: Typen. FastAPI erzwingt Pydantic-Modelle für Request- und Response-Schemas. Das klingt wie eine Einschränkung, ist aber das Gegenteil. Wenn drei Services miteinander reden, ist ein klar typisiertes Interface der einzige zuverlässige Vertrag. Django REST Framework macht ähnliches möglich, aber nicht erzwungen.
Automatische Dokumentation. Jeder FastAPI-Service generiert automatisch ein OpenAPI-Schema. Das bedeutet: Wenn ein neuer Mitarbeitender einen internen Service nutzen will, gibt es eine klare, immer aktuelle Referenz. Das hat die Einarbeitungszeit für neue Entwickler merklich verkürzt.
Migrations-Management. Django's ORM und Migrationssystem ist ausgereifter. Mit FastAPI und SQLAlchemy + Alembic haben wir mehr Konfigurationsarbeit — das ist ein realer Nachteil.
Außerdem: Manche Dinge, die Django mitbringt (Admin-Interface, Auth-System), müssen bei FastAPI explizit gebaut oder über Packages hinzugefügt werden. Das ist bewusste Komplexität — aber es ist Komplexität.
Für neue, fokussierte Microservices: FastAPI. Für eine einzige, große Anwendung die viele Standard-Features braucht: Django.
Wir bauen heute keine Django-Projekte mehr — aber das liegt an unserem konkreten Setup, nicht an einem generellen Urteil über das Framework.