Rebase face à Django
Django vous donne un admin échafaudé depuis vos modèles et une page rendue côté serveur pour chaque écran. Rebase vous donne le même échafaudage sous forme d'application React, plus l'API REST et le client typé dont l'admin est un consommateur — un client mobile ou un frontend séparé n'est donc pas une seconde chose à construire.
Rendu côté serveur, ou headless avec un SDK
Là où ça coince
L'admin de Django est lié à ses gabarits rendus côté serveur et à l'ORM derrière. Une application cliente séparée a besoin de sa propre API — Django REST Framework ou Ninja — et cela signifie des sérialiseurs, des viewsets, des routeurs et des classes de permissions décrivant les mêmes modèles une seconde fois. Rebase génère l'API et l'admin depuis une seule définition : il n'y a pas de seconde description à tenir alignée.
Ce que Rebase fait à la place
Rebase est API-first, et découplé par défaut.
- Le panneau est une application React autonome qui parle à ses propres API backend.
- La même définition produit aussi un SDK typé pour toute autre application que vous écrivez.
Rechargements de page, ou une SPA React
Là où ça coince
Un admin rendu côté serveur recharge la page à chaque enregistrement, et y placer un composant React ou une vue en direct revient à greffer une étape de build sur un gabarit. Le panneau Rebase est une application React dès le départ : un champ personnalisé est un composant que vous exportez.
Ce que Rebase fait à la place
Le panneau Rebase est une application React à page unique.
- La navigation ne fait pas d'aller-retour au serveur, et une action ne recharge pas la page.
- Les abonnements temps réel font qu'un enregistrement se met à jour quand quelqu'un d'autre l'édite, sans rafraîchir.
- Personnalisable avec des composants React ordinaires.
Ne changez pas
Quand rester sur Django
Quand votre équipe écrit du Python, quand vous avez besoin de son écosystème — bibliothèques de data science, Celery, la maturité de l'ORM — ou quand l'application est une app Django rendue côté serveur et qu'ajouter un backend séparé serait une seconde chose à exploiter. Django est un framework complet ; Rebase est un backend plus un panneau d'administration, et il n'essaie pas d'être le premier.
Rebase et Django, en réponses
Dois-je quitter Python ?
Pour le backend, oui — Rebase est en TypeScript. C'est le coût réel, et si l'expertise de votre équipe et votre code existant sont en Python, il est important. En échange, vous obtenez un seul langage sur toute la pile : les mêmes définitions de collection produisent le schéma de base de données, l'API REST, le SDK typé et le panneau d'administration — le frontend ne consomme donc pas une API que quelqu'un maintient à la main.
Rebase peut-il lire une base créée par Django ?
Oui, si c'est du PostgreSQL. Rebase se connecte à des tables existantes plutôt que de générer son propre schéma : les tables de Django — y compris ses tables d'auth, si vous voulez les modéliser — peuvent être décrites comme des collections et obtenir un panneau d'administration et une API sans toucher aux données.
Comment l'admin se compare-t-il à django-admin ?
django-admin est excellent et justement célèbre, et cette comparaison existe parce qu'on la réclame ailleurs. Les différences : le panneau de Rebase est en React, il s'étend donc dans le framework que la plupart des équipes frontend utilisent déjà, et il est généré aux côtés d'une API typée plutôt que d'être une surface séparée au-dessus de l'ORM. django-admin est bien plus éprouvé.
Quand Django est-il le meilleur choix ?
Quand votre équipe écrit du Python, quand vous avez besoin de son écosystème — bibliothèques de data science, Celery, la maturité de l'ORM — ou quand l'application est une app Django rendue côté serveur et qu'ajouter un backend séparé serait une seconde chose à exploiter. Django est un framework complet ; Rebase est un backend plus un panneau d'administration, et il n'essaie pas d'être le premier.
Où l'autorisation est-elle appliquée ?
Dans PostgreSQL, via la sécurité au niveau des lignes compilée depuis les définitions de collection. Django applique les permissions dans la couche applicative, ce qui est normal et sensé pour un framework. La différence apparaît quand autre chose que votre application Django atteint la base — un script, un rapport, un autre service — et que les règles voyagent avec les données, ou non.
Suis-je obligé d'auto-héberger Rebase ?
Non. Auto-hébergez-le et vous possédez les données, le code et la machine sur laquelle il tourne — c'est le mode par défaut et il est pleinement pris en charge. Ou déployez le même projet sur Rebase Cloud, qui tourne aujourd'hui avec de vrais clients et s'ouvre par vagues pendant sa bêta privée, facturé à la ressource plutôt qu'au siège. Votre code est identique dans les deux cas ; l'hébergement est une cible de déploiement, pas un embranchement.
Ne nous croyez pas sur parole.
La comparaison qui compte est celle que vous faites. Pointez Rebase vers une base Postgres que vous avez déjà et voyez comment il tient face à Django.