Discussion :

[Jade Emy]

ElectricSQL, une synchronisation active-active Postgres vers SQLite pour les applications "local-first", sort sa version v0.6, résolvant la réplication partielle dynamique.

Voici la version v0.6 d'ElectricSQL. Une couche de synchronisation "local-first" (local d'abord) qu'on peut utiliser pour construire des applications réactives, en temps réel, capables de fonctionner hors ligne, directement sur Postgres. Cette version est centrée sur Postgres avec un modèle de synchronisation basé sur la forme et une bibliothèque d'accès aux données sécurisée.

Electric - La synchronisation pour les applications modernes

ElectricSQL est une couche de synchronisation local-first qui fonctionne avec votre modèle de données existant et résout la réplication partielle dynamique. Elle prend en charge l'évolution réelle des schémas et fournit des API de synchronisation et d'accès aux données expressives et sûres.

Pour être honnête, nous voulions aussi nous appuyer sur nos recherches sur la préservation des invariants dans un système de base de données AP pour faire du vrai SQL avec intégrité dans un environnement local-first. De plus, nous voulions construire un système qui soit open source et conçu pour l'auto-hébergement, de sorte qu'il soit facile à adopter sans le verrouillage que l'on obtient avec les services propriétaires et hébergés. Nous n'en sommes qu'au début, mais le code est en place et le système fonctionne. Vous pouvez l'utiliser dès aujourd'hui pour créer des applications réactives, en temps réel et en local. En utilisant Postgres et SQLite standard.

Par couche de synchronisation, nous entendons une réplication active-active bidirectionnelle avec une cohérence transactionnelle causale+ entre Postgres dans le nuage (généralement !) et SQLite sur l'appareil local.

Les applications lisent et écrivent des données directement depuis et vers une base de données SQLite locale intégrée. Les écritures déclenchent immédiatement la réactivité, de sorte que les données sont visibles et que les composants se redessinent instantanément. Les données sont ensuite synchronisées en arrière-plan par Postgres, en temps réel, entre les utilisateurs et les appareils.

Par conséquent, les applications créées avec Electric sont instantanément utilisables, supportent naturellement la collaboration multi-utilisateurs en temps réel et fonctionnent par défaut hors ligne. Comme il s'agit d'un système sans conflit et sans retour en arrière, les applications gèrent naturellement la concurrence et les écritures qui se chevauchent.

Directement sur Postgres

Electric est construit sur le logiciel libre standard Postgres. Postgres est la base de données centrale, la source de durabilité et le plan de contrôle pour gérer la propagation des données (DML) et le schéma de la base de données (DDL) à vos applications local-first. Ce schéma est ensuite utilisé pour générer un client de base de données à sécurité de type avec prise en charge des invariants relationnels.

Electric est conçu pour fonctionner avec les modèles de données Postgres existants. Cela signifie qu'il fonctionne aussi bien pour les nouvelles applications que pour les applications existantes. L'objectif est de pouvoir intégrer Electric à Postgres pour un accès local instantané, de la même manière que vous pouvez intégrer Hasura ou PostgREST pour des API GraphQL ou REST instantanées.

Invariants relationnels standard

L'un des principaux objectifs de conception d'ElectricSQL est de fournir un véritable support SQL.

Nous en sommes encore aux premières étapes du développement. Pour l'instant, par exemple, la prise en charge des invariants est limitée à l'intégrité référentielle à l'aide de compensations. Cependant, notre objectif est de supporter*:

• tous les types de données Postgres intégrés, les types de données d'extension les plus courants et un mécanisme d'extension pour prendre en charge des types de données arbitraires
• tous les invariants relationnels, y compris l'intégrité référentielle, l'intégrité référentielle à travers les frontières de réplication, les contraintes uniques et les contraintes de vérification.

Nous nous appuyons ici sur des recherches dont nous sommes les auteurs et que nous mettons en œuvre sous la forme de Rich-CRDT.

Réplication partielle dynamique

Stratégies de synchronisation

Lorsque vous construisez des applications locales ou hors ligne, vous pouvez choisir d'employer un certain nombre de stratégies de synchronisation. Des requêtes épinglées aux abonnements en direct, en passant par le filtrage basé sur les lignes ou sur les schémas.

Avec Electric, nous avons travaillé dur pour concevoir un système où vous pouvez exprimer tous ces différents modèles. Pour ce faire, nous utilisons une primitive appelée Shapes.

Synchronisation basée sur les formes

Une forme est un ensemble de données liées qui sont synchronisées sur l'appareil local. Elle est définie par :

• une table, dans votre schéma DDL électrifié, comme les projets
• une requête, avec des clauses where utilisées pour filtrer les lignes de cette table
• un arbre d'inclusion, un graphe acyclique dirigé de données liées (comme le graphe d'association que vous pourriez inclure avec une requête ORM).

Vous pouvez synchroniser des formes larges et peu profondes, telles qu'un petit ensemble de colonnes provenant de toutes les lignes d'une table. Vous pouvez synchroniser des formes imbriquées profondes, telles qu'un projet individuel avec tout son contenu connexe.

Avec cette version v0.6, Electric publie la première itération de l'implémentation de ce système. L'implémentation actuelle :

• fournit la fonction sécurisée sync()
• charge efficacement les formes
• déduplique les formes qui se chevauchent
• maintient des abonnements de formes résilients et persistants

Les where-clauses filtrées et les include-trees sont à venir dans la v0.6. Après cela, nous étendrons la sémantique de l'abonnement et de la rétention et nous nous pencherons sur la prise en charge de la segmentation des données.

Des applications modernes, locales-first

Nous espérons que cela vous donne une idée de la version v0.6 d'ElectricSQL. C'est une synchronisation pour les applications modernes. Par les inventeurs des CRDT. Que vous pouvez utiliser pour construire des applications réactives, en temps réel, locales d'abord en utilisant des technologies open-source standard.

Avec ElectricSQL, vous obtiendrez des applications qui sont :

• rapides, instantanées : sans décalage ni chargement de spinners
• naturellement en temps réel : avec un support natif pour la collaboration multi-utilisateurs
• naturellement hors ligne : avec des garanties de simultanéité et d'intégrité sans conflit
• naturellement local-first : avec la propriété des données intégrée et la synchronisation dans le nuage en option.

Ainsi, vous utilisez des technologies open-source standard :

• Postgres open source standard pour le backend
• SQLite open source standard (avec prise en charge complète de SQL) sur le front-end

Lié à un protocole de socket web Protobuf open source et à un service de synchronisation Elixir open source qui tire parti de la concurrence et de la résilience de BEAM.

Source : Electric

Et vous ?

Que pensez-vous de cette mise à jour de ElectricSQL ?

Voir aussi :

PostgreSQL 16 est disponible, la dernière version de la base de données open source apporte des améliorations au parallélisme des requêtes et à la réplication logique

IvorySQL : un PostgreSQL open source compatible avec Oracle, pourrait répondre au besoin de migrer des applications Oracle vers l'open source Postgres

Google aurait pour objectif de s'emparer d'une partie des charges de travail d'Oracle en proposant un service de migration vers PostgreSQL grâce à un ensemble de services et d'outils d'automatisation