Rebase face à Appwrite
Les deux vous donnent l'auth, une base de données, du stockage, des fonctions et du temps réel derrière une API. La différence, c'est la base de données. Celle d'Appwrite appartient à la plateforme : vous y accédez par l'API d'Appwrite, et son option SQL native vient sans la plateforme. Rebase génère l'API, le SDK typé et un panneau d'administration sur un Postgres qui vous appartient, et impose l'accès dans la base elle-même.
La plateforme ou SQL — ou les deux
Là où ça coince
Appwrite 2.0 fait tourner TablesDB sur PostgreSQL par défaut, avec des colonnes de relation et des transactions. Mais la base appartient à Appwrite : il crée et gère le schéma, vous accédez aux données par son API de requêtes, REST ou GraphQL plutôt qu'en SQL, et rien dans sa documentation ne permet de le brancher sur les tables d'une base que vous avez déjà. Appwrite Cloud vend désormais aussi du PostgreSQL natif avec SQL complet — que sa propre documentation décrit comme n'ayant aucune couche Appwrite entre les deux. Vous choisissez entre la plateforme et la base.
Ce que Rebase fait à la place
Rebase génère la plateforme au-dessus d'un Postgres qui vous appartient, il n'y a donc rien à choisir.
- Pointez-le vers une base existante et il déduit les collections des tables déjà présentes.
- L'API générée et psql lisent les mêmes tables, donc les outils de BI et les jobs ETL continuent de fonctionner.
- Quand l'API générée ne suffit pas, écrivez la jointure ou la vue en SQL.
Les permissions dans le serveur, ou dans la base
Là où ça coince
Le modèle de permissions d'Appwrite est bon : lecture, création, modification et suppression sur les tables et les lignes, pour tout visiteur, les utilisateurs connectés, un utilisateur, une équipe, un rôle d'équipe ou un label, fermé par défaut et respecté en temps réel. Mais c'est le serveur d'Appwrite qui l'impose, donc il protège les requêtes qui passent par ce serveur. Une clé d'API serveur avec les bons scopes le contourne entièrement, et le PostgreSQL natif de Cloud n'en a rien.
Ce que Rebase fait à la place
Rebase compile les règles d'accès en sécurité au niveau des lignes de Postgres, pour qu'elles tiennent quel que soit le chemin par lequel arrive la requête.
- Les règles sont déclarées sur la collection, en TypeScript, et arrivent dans la base comme de vraies politiques.
- Une table sans RLS n'est pas servie du tout, et une clé d'API ne contourne jamais une politique.
- Les abonnements temps réel sont livrés sous les mêmes politiques que toute autre lecture.
Une console pour développeurs, ou un panneau d'administration pour votre équipe
Là où ça coince
La console Appwrite est un bon outil de développeur : un éditeur de tables, l'import et l'export CSV, des logs et, depuis la 2.0, un explorateur d'API et un terminal pour la CLI. Elle n'est pas faite pour les personnes qui font tourner l'activité. Pas de formulaires sur mesure ni de vues de workflow, rien qu'un agent du support ou une rédactrice reconnaîtrait comme son outil — ce panneau reste donc un projet que vous construisez vous-même sur le SDK.
Ce que Rebase fait à la place
Rebase génère Rebase CMS, un panneau d'administration React, depuis la même définition de collection que l'API.
- Des tables façon tableur, des formulaires et des tableaux kanban, générés depuis le schéma.
- On peut le confier à des collègues non techniques, parce que les politiques sont dans la base.
- Remplacez n'importe quelle partie par vos propres composants React.
Ne changez pas
Quand rester sur Appwrite
Quand votre application est en Flutter, Swift ou Kotlin : Appwrite a des SDK clients officiels pour les trois, et le SDK typé de Rebase n'existe qu'en TypeScript. Quand vous voulez des notifications push et des SMS, des dizaines de fournisseurs OAuth ou des fonctions en Python, Go ou Dart depuis la même plateforme — Appwrite les fournit et Rebase non. Et quand personne hors de l'équipe technique n'ouvrira le back-office et que rien d'autre que votre application ne lira jamais les données, une base que vous ne pouvez pas atteindre directement n'est pas un coût que vous sentirez.
Rebase et Appwrite, en réponses
Puis-je migrer un projet Appwrite vers Rebase ?
Oui, mais c'est une migration et non un changement de connexion, parce que la base d'Appwrite appartient à Appwrite même quand elle tourne sur PostgreSQL. Les lignes sortent par son API et entrent dans des tables Postgres que vous définissez — le plus souvent presque une pour une, puisque TablesDB est déjà fait de tables, de lignes et de colonnes, et que les colonnes de relation deviennent des clés étrangères. Les utilisateurs, les fichiers et les fonctions sont des implémentations d'Appwrite : on les déplace ou on les réécrit, on ne les branche pas.
Appwrite tourne désormais sur PostgreSQL. Qu'est-ce qui reste différent ?
À qui la base obéit. Un Appwrite 2.0 auto-hébergé utilise PostgreSQL par défaut, mais Appwrite crée le schéma, vérifie les permissions dans son propre serveur et expose les données par son API de requêtes, REST et GraphQL, pas en SQL. Le PostgreSQL natif d'Appwrite Cloud vous donne SQL — et en échange, ni SDK Appwrite ni permissions de la plateforme. Rebase est les deux à la fois : l'API, le SDK typé et le panneau d'administration sont générés sur des tables que vous pouvez aussi ouvrir dans psql, sous la même sécurité au niveau des lignes.
Rebase couvre-t-il les fonctions d'authentification d'Appwrite ?
La plupart, avec des manques qu'il faut nommer. Rebase livre e-mail et mot de passe, liens magiques, codes à usage unique par e-mail, sessions anonymes, multifacteur TOTP, clés d'API à portée limitée et douze fournisseurs OAuth et OIDC — ou votre propre adaptateur devant Auth0, Clerk ou Firebase Auth. Appwrite a nettement plus de fournisseurs OAuth, la connexion par téléphone et SMS, et l'e-mail ou le SMS comme second facteur. Aucun des deux n'a de SAML intégré pour vos utilisateurs finaux. Ce que Rebase apporte, c'est l'endroit où vivent les utilisateurs : une table dans votre propre Postgres, que les politiques et les requêtes peuvent joindre.
Quand Appwrite est-il le meilleur choix ?
Quand votre application est en Flutter, Swift ou Kotlin : Appwrite a des SDK clients officiels pour les trois, et le SDK typé de Rebase n'existe qu'en TypeScript. Quand vous voulez des notifications push et des SMS, des dizaines de fournisseurs OAuth ou des fonctions en Python, Go ou Dart depuis la même plateforme — Appwrite les fournit et Rebase non. Et quand personne hors de l'équipe technique n'ouvrira le back-office et que rien d'autre que votre application ne lira jamais les données, une base que vous ne pouvez pas atteindre directement n'est pas un coût que vous sentirez.
Rebase a-t-il des fonctions, du stockage et de la messagerie comme Appwrite ?
Des fonctions et du stockage, oui ; de la messagerie, seulement par e-mail. Rebase a des fonctions TypeScript montées comme routes d'API, des tâches cron, des jobs en arrière-plan avec nouvelles tentatives et du stockage de fichiers sur disque local, sur tout service compatible S3 ou sur Google Cloud Storage. Il envoie des e-mails transactionnels par SMTP, mais n'a ni notifications push ni SMS, et ses fonctions sont uniquement en TypeScript, là où celles d'Appwrite tournent dans plus d'une douzaine de langages.
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 à Appwrite.