Le backend · et le panneau qui va avec

Une définition.
Tout ce qu'elle produit.

Rebase transforme une base Postgres en backend produit — REST, un SDK typé, le temps réel, l'auth, le stockage et un contrôle d'accès que la base applique elle-même. Le panneau d'administration se rend depuis le même fichier, et seulement si vous le demandez.

Le panneau

Pensé pour votre façon
de travailler

Pas un énième outil à apprendre — Rebase fonctionne avec votre base de données et votre workflow existants.

Chaque vue. Zéro code.

Le SQL reste roi

Éditeur visuel, vrai TypeScript

Ce que vous écrivez, ce que vous obtenez

Ce fichier devient l'API et le panneau d'administration.

Les champs, leurs types, ce qui est obligatoire : vous l'écrivez une fois, en TypeScript. De ce seul fichier, Rebase crée la table en base de données, sert les données via une API avec un client typé et affiche les écrans où votre équipe consulte et modifie les lignes.

Le backend

La partie qui tourne sans navigateur

Un projet Rebase, c'est un serveur Hono et un schéma Drizzle. Il sert vos données en REST, diffuse les changements en WebSocket, émet et fait tourner les jetons, stocke les fichiers, exécute vos tâches planifiées, et publie un document OpenAPI toujours à jour parce que personne ne l'écrit.

Chacune de ces requêtes s'exécute sous un rôle Postgres restreint. C'est la partie à lire deux fois : l'autorisation est une propriété de votre base de données, pas de ce processus.

Ce que vous cessez de maintenir

  • Contrôleurs CRUD, sérialiseurs et validation des requêtes
  • Un back-office fait main, et le sprint qu'il coûte chaque trimestre
  • La plomberie JWT, la rotation des refresh et l'e-mail de réinitialisation
  • Des vérifications de permissions éparpillées dans les handlers de routes
  • Des endpoints d'upload de fichiers et des helpers d'URL signées
  • Un runner de cron, un dispatcher de webhooks et une table d'audit
  • Le document OpenAPI que personne n'a pensé à mettre à jour
  • Un second modèle de données, synchronisé à la main avec le premier

Une définition

Une définition, toutes les surfaces.

Un tableur, un tableau kanban, une galerie, un éditeur de blocs, une vue React personnalisée — chaque écran ci-dessous lit la même collection via la même API, sous les mêmes politiques. Rien ici n'est un second modèle de données.

Le produit entier

Tout ce que Rebase livre, sur un seul écran

La colonne de gauche tourne sans rien installer d'autre. Celle de droite est à une dépendance, et la supprimer ne déplace pas une seule réponse d'API.

Layer 01

Le backend

toujours actif
  • API REST/api/data/:collection

    CRUD, filtrage, tri, pagination, relations

  • SDK typé@rebasepro/client

    Généré depuis vos collections, vérifié à la compilation

  • Temps réellisten()

    Abonnements aux lignes, canaux et présence via WebSocket

  • Auth/api/auth/*

    JWT d'accès et de rafraîchissement, OAuth, MFA, rôles, clés d'API

  • Stockage/api/storage/*

    Local, compatible S3 ou GCS, routé par champ

  • Fonctions et cronfunctions/

    Vos propres routes Hono et tâches planifiées, montées automatiquement

  • Row-level securitysecurityRules

    Des policies compilées dans Postgres — fermées par défaut

  • OpenAPI/api/docs

    Une spec et un explorateur, régénérés avec le schéma

Layer 02

Le panneau d'administration

inclus
  • Vues de collectionenabledViews

    Tableau, cartes, liste et Kanban sur les mêmes lignes

  • Formulaires d'entitéproperties

    Générés depuis les properties, avec validation et relations

  • Votre Reactadmin.Field

    Champs personnalisés, aperçus, vues et actions d'entité

  • Utilisateurs et rôlesRBAC

    Les mêmes rôles que lisent vos policies, gérés par des humains

  • Rebase Studio/studio

    Studio est l'espace de travail du développeur. Il s'enregistre dans le même panneau que CMS.

Le panneau est une application React qui parle aux endpoints de gauche, sous la même sécurité au niveau des lignes que votre propre client. Il n'y a pas de canal privé pour les données.

Les deux couches, une commande.

Échafaudez un projet sur votre propre Postgres et voyez exactement quelles parties vous gardez.

~pnpm dlx @rebasepro/cli init