Rebase gegen Django
Django gibt dir ein aus deinen Modellen gescaffoldetes Admin und für jeden Screen eine serverseitig gerenderte Seite. Rebase gibt dir dasselbe Gerüst als React-App, dazu die REST-API und den typisierten Client, von dem das Admin ein Konsument ist — ein Mobile-Client oder ein separates Frontend ist damit keine zweite Sache, die du baust.
Serverseitig gerendert, oder headless mit SDK
Wo es wehtut
Djangos Admin hängt an seinen serverseitig gerenderten Templates und am ORM dahinter. Eine separate Consumer-App braucht eine eigene API — Django REST Framework oder Ninja — und das heißt Serializer, ViewSets, Router und Permission-Klassen, die dieselben Modelle ein zweites Mal beschreiben. Rebase erzeugt API und Admin aus einer Definition, also gibt es keine zweite Beschreibung, die im Gleichschritt bleiben muss.
Was Rebase stattdessen macht
Rebase ist API-first und standardmäßig entkoppelt.
- Das Panel ist eine eigenständige React-App, die mit ihren eigenen Backend-APIs spricht.
- Dieselbe Definition erzeugt außerdem ein typisiertes SDK für jede andere Anwendung, die du schreibst.
Seiten-Reloads, oder eine React-SPA
Wo es wehtut
Ein serverseitig gerendertes Admin lädt bei jedem Speichern die Seite neu, und eine React-Komponente oder eine Live-View hineinzubekommen heißt, einen Build-Schritt an ein Template zu schrauben. Das Rebase-Panel ist von vornherein eine React-App — ein eigenes Feld ist eine Komponente, die du exportierst.
Was Rebase stattdessen macht
Das Rebase-Panel ist eine React-Single-Page-Application.
- Navigation macht keinen Server-Roundtrip, und eine Aktion lädt die Seite nicht neu.
- Realtime-Subscriptions sorgen dafür, dass ein Datensatz sich aktualisiert, wenn ihn jemand anders bearbeitet — ohne Neuladen.
- Anpassbar mit gewöhnlichen React-Komponenten.
Nicht wechseln
Wann du bei Django bleiben solltest
Wenn dein Team Python schreibt, wenn du sein Ökosystem brauchst — Data-Science-Bibliotheken, Celery, die Reife des ORM — oder wenn die Anwendung eine serverseitig gerenderte Django-App ist und ein separates Backend eine zweite Sache zum Betreiben wäre. Django ist ein vollständiges Framework; Rebase ist ein Backend plus Admin-Panel und versucht nicht, Ersteres zu sein.
Rebase und Django, beantwortet
Muss ich Python verlassen?
Fürs Backend ja — Rebase ist TypeScript. Das ist der ehrliche Preis, und wenn die Expertise deines Teams und dein bestehender Code Python sind, ist er hoch. Dafür bekommst du eine Sprache über den gesamten Stack: Dieselben Collection-Definitionen erzeugen das Datenbankschema, die REST-API, das typisierte SDK und das Admin-Panel — das Frontend konsumiert also keine API, die jemand von Hand pflegt.
Kann Rebase eine von Django angelegte Datenbank lesen?
Ja, wenn es PostgreSQL ist. Rebase verbindet sich mit bestehenden Tabellen, statt ein eigenes Schema zu erzeugen — Djangos Tabellen, auch die Auth-Tabellen, wenn du sie modellieren willst, lassen sich als Collections beschreiben und bekommen ein Admin-Panel und eine API, ohne dass die Daten angefasst werden.
Wie vergleicht sich das Admin mit django-admin?
django-admin ist ausgezeichnet und zu Recht berühmt, und dieser Vergleich existiert, weil er anderswo verlangt wird. Die Unterschiede: Rebases Panel ist React, es erweitert sich also in dem Framework, das die meisten Frontend-Teams ohnehin nutzen, und es entsteht neben einer typisierten API statt als separate Oberfläche über dem ORM. django-admin ist mit großem Abstand kampferprobter.
Wann ist Django die bessere Wahl?
Wenn dein Team Python schreibt, wenn du sein Ökosystem brauchst — Data-Science-Bibliotheken, Celery, die Reife des ORM — oder wenn die Anwendung eine serverseitig gerenderte Django-App ist und ein separates Backend eine zweite Sache zum Betreiben wäre. Django ist ein vollständiges Framework; Rebase ist ein Backend plus Admin-Panel und versucht nicht, Ersteres zu sein.
Wo wird die Autorisierung durchgesetzt?
In PostgreSQL, über Row-Level Security, die aus den Collection-Definitionen kompiliert wird. Django setzt Berechtigungen in der Anwendungsschicht durch, was für ein Framework normal und vernünftig ist. Der Unterschied zeigt sich, wenn etwas anderes als deine Django-App die Datenbank erreicht — ein Skript, ein Report, ein anderer Dienst — und die Regeln entweder mit den Daten mitreisen oder eben nicht.
Muss ich Rebase selbst hosten?
Nein. Hoste es selbst, und dir gehören die Daten, der Code und die Maschine, auf der es läuft — das ist die Voreinstellung und wird voll unterstützt. Oder deploy dasselbe Projekt auf Rebase Cloud, das heute mit echten Tenants läuft und während der Private Beta in Wellen öffnet, abgerechnet pro Ressource statt pro Sitz. Dein Code ist in beiden Fällen identisch; Hosting ist ein Deployment-Ziel, keine Abzweigung.
Glaub uns nicht einfach.
Der Vergleich, der zählt, ist der, den du selbst machst. Richte Rebase auf ein Postgres, das du schon hast, und sieh, wie es sich neben Django hält.