InstantDB – « Firebase moderne » : une base de données côté client en open source et en temps réel

• Une base de données côté client qui permet de créer facilement des applications collaboratives en temps réel comme Notion ou Figma
• Écrivez des requêtes relationnelles et Instant se charge de la récupération des données, de la vérification des autorisations et du cache hors ligne
• En cas de modification des données, les mises à jour optimistes et les rollbacks sont également gérés automatiquement
• Toutes les requêtes prennent en charge le mode multijoueur par défaut
• Prend aussi en charge les mises à jour temporaires comme les curseurs ou le statut en ligne
• Fournit actuellement des SDK pour Javascript, React et React Native

Motivation du développement

• Le développement d’applications modernes exige beaucoup de travail : configuration du serveur, base de données, cache, ORM, configuration des endpoints, etc.
• Il faut aussi écrire le code côté client, gérer l’état et dessiner l’UI
• Si l’on ajoute des fonctionnalités multijoueur, il faut envisager un serveur avec état, et pour le mode hors ligne, IndexedDB et une file de transactions
• À chaque ajout de fonctionnalité, il faut réécrire en boucle les modèles, les endpoints, la gestion d’état et l’UI
• En 2021, ils ont réalisé que la plupart des problèmes rencontrés par les ingénieurs UI sont en réalité des problèmes de base de données
• Avec une base de données côté client, il suffit d’écrire des requêtes sans avoir à se soucier de la gestion d’état, des endpoints ou du cache local
• Si les requêtes prennent en charge le multijoueur par défaut, plus besoin de se préoccuper d’un serveur avec état
• Si la base de données prend en charge les rollbacks, on obtient gratuitement les mises à jour optimistes
• C’est pour cela qu’Instant a été développé. Instant fournit une base de données utilisable côté client, afin de permettre de se concentrer sur la construction de l’UX

Aperçu de l’architecture

• Instant stocke toutes les données utilisateur sous forme de triplets dans une grande base de données Postgres unique
• Une configuration multi-tenant permet de proposer une offre gratuite
• Un serveur de synchronisation écrit en Clojure communique avec Postgres
• Ils ont écrit un moteur de requêtes qui comprend InstaQL, similaire à Datalog et GraphQL
• Inspiré par WorldStore d’Asana et LiveGraph de Figma, il suit le WAL de Postgres pour détecter les nouvelles données et invalider les requêtes concernées
• Côté frontend, ils ont écrit un triple store côté client
• Le SDK stocke le cache des requêtes récentes dans IndexedDB sur le web, et dans AsyncStorage sur React Native
• Toutes les données passent par un système d’autorisations propulsé par la bibliothèque CEL de Google

Résumé de GN⁺

• Instant est une base de données côté client qui facilite la création d’applications collaboratives en temps réel
• Les requêtes relationnelles gèrent automatiquement la récupération des données, la vérification des autorisations et le cache hors ligne
• Les fonctionnalités multijoueur, les mises à jour optimistes et les rollbacks sont pris en charge par défaut
• Inspiré par Asana et Figma, le système suit le WAL de Postgres pour détecter les nouvelles données et invalider les requêtes concernées
• Grâce à un triple store côté client et à un système d’autorisations, la gestion des données est traitée efficacement

[stargt]

C’est un projet vraiment prometteur, dans la même veine que Supabase.

[GN⁺]

Avis Hacker News

• Fondateur de Firebase : enthousiaste à propos de la combinaison hors ligne, temps réel, requêtes relationnelles et open source d’Instant. Il y avait beaucoup de demandes pour les requêtes relationnelles. Le client Firebase est open source, mais l’ouverture du backend a échoué

• Retour : les exemples de code ne sont pas complets. L’origine de transact et useQuery n’est pas claire. Les petits détails comptent

• Possibilité d’auto-hébergement : certaines parties de l’outil ne peuvent souvent pas être auto-hébergées. Il faut le préciser clairement

• Alternative au modèle offline-first : choix de PowerSync. WatermelonDB est également correct. ElectricSQL est encore immature. CouchDB et PocketDB ne sont pas modernes. PowerSync et Supabase devraient être utilisés comme backend

• Relation avec les apps CRUD : difficile de comprendre la relation entre les apps CRUD et le concept d’InstantDB ou de Firebase. Pour un éditeur de texte collaboratif, une implémentation JavaScript de CRDT serait utilisée

• Expérience avec Instant : utilisation d’Instant pendant 6 mois avec satisfaction. Les fonctionnalités temps réel, relationnelles et hors ligne étaient importantes. D’autres outils ont été essayés sans succès. Depuis Instant, aucun autre outil n’est utilisé

• Résumé du système de permissions : Firebase sépare la logique de récupération/mise à jour des données et les politiques d’accès. Instant évalue la logique d’autorisation en fonction des résultats de la requête. Firebase vérifie la sécurité avant l’exécution de la requête

• Exposition du moteur Datalog : il existe d’autres moteurs Datalog prenant en charge les requêtes récursives. Question sur la possibilité de mise en cache et de jointures des requêtes. Dans le passé, il existait aussi un Java InstantDB portant le même nom. Une liste d’autres moteurs Datalog implémentés en Clojure est fournie

  • Datomic
  • XTDB
  • Datascript
  • Datalevin
  • datahike
  • Naga

• Souhait d’une expérience type ActiveRecord : envie de travailler dans React/Vue/Solid d’une manière proche d’ActiveRecord. Souhait d’une API de type graphe d’objets. Pas envie d’une API de type SQL. L’ORM devrait fonctionner comme si le graphe d’objets complet était en mémoire

• Problème de performances des triple stores : les triple stores sont peu performants lorsque la plupart des requêtes récupèrent l’objet entier ou plusieurs champs du même objet. Postgres n’est pas non plus particulièrement excellent. Demande de retours d’expérience à ce sujet