Rebase
vs
Hasura

Rebase face à Hasura

Hasura génère une API GraphQL et une console pour la construire. Rebase génère du REST, un SDK TypeScript typé et un panneau d'administration dans lequel votre équipe d'exploitation peut travailler, depuis la même définition de collection — et ses permissions se compilent en politiques Postgres plutôt qu'en métadonnées appliquées par le moteur.

Le vide côté frontend

Une API, et ensuite ?

Là où ça coince

Hasura se concentre sur la couche API. Il génère du GraphQL vite et ne donne rien à vos collègues non techniques — le back-office reste à votre charge, ou à louer chez un constructeur d'outils internes.

Ce que Rebase fait à la place

Rebase génère la couche API et la couche application depuis le même fichier.

  • Des endpoints REST et un SDK typé, générés depuis votre schéma Postgres.
  • Rebase génère aussi Rebase CMS — un panneau d'administration React avec édition, audit et tableaux de bord — depuis la même définition.
La complexité de la logique métier

Où tourne la logique métier

Là où ça coince

Faire tourner de la logique métier dans Hasura — facturer un client Stripe à l'insertion d'une ligne — passe par des Actions ou des Event Triggers, donc par la mise en place et la maintenance d'un serveur distinct pour recevoir les webhooks.

Ce que Rebase fait à la place

Rebase, c'est un seul backend Node.js.

  • Votre logique métier s'exécute dans le même processus que les endpoints générés.
  • Aucun saut réseau pour un déclencheur interne, et aucune configuration de webhook à tenir synchronisée.
  • Un dépôt TypeScript, un déploiement.

Ne changez pas

Quand rester sur Hasura

Quand GraphQL est la décision produit, quand vous devez fédérer plusieurs sources de données derrière un seul graphe, ou quand vos clients génèrent déjà du code depuis un schéma GraphQL. C'est le terrain de Hasura.

Questions

Rebase et Hasura, en réponses

REST ou GraphQL ?

Rebase génère une API REST et un SDK TypeScript typé ; Hasura génère du GraphQL. Si GraphQL est une exigence — un graphe fédéré, des clients qui en dépendent, un schéma existant assemblé entre services — Hasura est fait pour cela et Rebase non. Si vous vouliez surtout une bonne API sur Postgres sans l'écrire, le SDK typé vous y mène avec moins de machinerie entre les deux.

Rebase peut-il tourner sur une base que Hasura sert déjà ?

Oui. Les deux pointent vers une base PostgreSQL existante plutôt que de la posséder : le même schéma peut soutenir les deux pendant votre évaluation. Les métadonnées de Hasura vivent dans son propre schéma et sont laissées tranquilles.

Comment se comparent les permissions ?

Le système de permissions de Hasura est défini dans ses métadonnées et appliqué par le moteur au moment où il construit chaque requête — puissant et très bien conçu. Rebase compile les règles d'accès en sécurité au niveau des lignes de PostgreSQL : l'application se fait dans la base de données et survit à n'importe quel client, y compris ceux qui ne passent jamais par Rebase. Le compromis, c'est l'expressivité contre la portée.

Qu'ajoute Rebase que Hasura n'a pas ?

Un panneau d'administration que vos collègues non techniques peuvent utiliser, généré depuis les mêmes définitions que l'API. La console de Hasura est un outil de développeur pour construire et inspecter le graphe ; ce n'est pas un back-office et cela ne cherche pas à l'être. Si vous comptiez construire une interface interne au-dessus de Hasura, c'est la pièce qu'apporte Rebase.

Quand Hasura est-il le meilleur choix ?

Quand GraphQL est la décision produit, quand vous devez fédérer plusieurs sources derrière un seul graphe, ou quand vos clients génèrent déjà du code depuis un schéma GraphQL. C'est le terrain de Hasura.

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 à Hasura.

~pnpm dlx @rebasepro/cli init