ElectricSQL, synchronisation active-active de Postgres vers SQLite pour des applications web/app local-first

• Une plateforme pour développer des applications local-first, réactives (Reactive) et en temps réel (Realtime) à partir de Postgres dans le cloud et de SQLite en local
• Local-First
  • Le code de l’application communique directement avec une base embarquée en SQLite, tandis que les données se synchronisent dynamiquement en arrière-plan avec le Postgres du cloud via une réplication active-active
  • Cela permet la collaboration multi-utilisateur et une gestion sans conflit (Conflict-Free)
• Avec ElectricSQL, il est possible d’utiliser tel quel le Postgres local
• Conçu pour rendre les applications immédiatement réactives et constamment rapides grâce à un accès aux données prioritairement local
• Offre une simplicité opérationnelle et réduit la diversité ainsi que la charge de travail des services backend en s’appuyant sur un protocole de réplication simple, extensible et standardisé
• Compatible avec les systèmes existants basés sur Postgres et fonctionne avec les modèles de données existants

[sixmen]

J’avais créé une application principalement côté client parce que je préfère ce qui peut fonctionner sans serveur, puis plus tard, quand il est devenu nécessaire de l’intégrer à un serveur, je suis passé à une synchronisation active-active.

Pour le premier service, j’ai introduit le concept d’OT et je l’ai implémenté manuellement ; pour le second, en cherchant une solution externe, j’avais choisi Couchbase (à l’époque, j’avais aussi étudié PouchDB et Realm)...

La conclusion, c’est que dans la mesure du possible, mieux vaut éviter. La gestion des données devient ingérable (même si cela tient aussi en partie aux particularités de la base Couchbase).

[GN⁺]

Avis Hacker News

• ElectricSQL est une nouvelle technologie qui permet une synchronisation active-active entre Postgres et SQLite pour les applications local-first.
• Cette technologie a été saluée pour son approche originale de la gestion de la connexion entre SQLite côté client, une couche open source de CRDT/synchronisation, et Postgres.
• ElectricSQL permet à la base de données Postgres de servir de source centrale de vérité pour l’ensemble des données et des comptes utilisateurs, tandis que le contenu privé de chaque utilisateur peut être isolé dans sa propre base SQLite puis synchronisé.
• ElectricSQL pourrait être utilisé dans des workflows CI pour écrire rapidement des tests d’intégration à partir d’une partie de données réelles ou sélectionnées.
• ElectricSQL est considéré comme une étape importante vers le renouveau des applications local-first, même si de nombreux défis restent encore à surmonter dans ce domaine.
• La possibilité d’utiliser un chiffrement de bout en bout pour une partie de l’état des applications utilisant ElectricSQL a été soulevée.
• Certains utilisateurs ont exprimé des inquiétudes quant à la complexité de compréhension de l’état avec les CRDT, ainsi qu’aux problèmes que cela pourrait poser aux utilisateurs.
• Des questions subsistent sur le modèle économique d’ElectricSQL, notamment pour savoir s’il s’agira d’un service cloud complet ou si seule la composante Elixir sera hébergée.
• Les utilisateurs s’interrogent sur la validation ou l’authentification des modifications réintégrées dans la base de données racine, ainsi que sur la manière dont ElectricSQL répond au risque qu’un client malveillant envoie un flux de données arbitraire à synchroniser vers cette base.
• ElectricSQL a été comparé à d’autres solutions comme PouchDB et CouchDB, et des utilisateurs ont exprimé leur intérêt pour essayer cette nouvelle technologie.
• Le lancement d’ElectricSQL a été globalement bien accueilli, et de nombreux utilisateurs se sont dits enthousiastes quant au potentiel de cette technologie pour les logiciels local-first.