- Couche de données de gestion d’état conçue pour permettre le développement d’applications haute performance sans la charge de développer une logique de synchronisation
- Se caractérise par l’utilisation de SQLite réactif et d’un moteur de synchronisation intégré
- Approche local-first, offrant de hautes performances même hors ligne, avec synchronisation automatique lors du rétablissement du réseau
- Toutes les opérations de gestion d’état sont exécutées rapidement sur une base de données SQLite locale
- Flux de données réactif : lorsqu’une donnée change, un événement est immédiatement déclenché pour les listeners connectés à l’UI, ce qui permet de refléter les changements d’état en temps réel
- Peut être appliqué à divers environnements (web, mobile, desktop, etc.)
- Par rapport aux outils de gestion d’état existants, offre de meilleurs résultats en matière de performances natives et de cohérence des données
2 commentaires
La démo sur la page d’accueil est vraiment très réussie. À force de cliquer un peu partout, ça donne envie d’essayer.
Avis Hacker News
Bonjour, je suis le cofondateur de LiveStore (j’avais auparavant créé Prisma).
J’ai développé LiveStore d’abord pour mon propre usage, en construisant depuis quatre ans Overtone, un client musical haute performance de niveau natif.
LiveStore ajoute une couche de signaux réactive à SQLite et la combine avec une synchronisation basée sur l’event sourcing (similaire à Git)
J’ai évalué pas mal d’environnements local-first, et il y a très peu de solutions qui règlent ça aussi proprement que LiveStore
tinyBase est aussi un outil relativement mature dans le même espace, mais avec une architecture différente (CRDTs vs event sourcing)
J’ai une question : pourquoi limiter le volume de données à 1 Go ? Ne pourrait-on pas proposer une option pour stocker davantage de données dans SQLite et les conserver sur disque ?
Est-ce qu’on ne pourrait pas simplement changer le mode de persistance via la configuration ?
La multi-tenance me semble aussi être un scénario intéressant : dans un cas comme JIRA où chaque organisation a besoin d’un namespace distinct, ce serait bien que chaque utilisateur ne reçoive pas tous les tickets, mais seulement ceux de son équipe ou département
En gros, la base locale devient alors un sous-ensemble de l’ensemble des données. Ce serait vraiment génial d’avoir un serveur de sync prêt à l’emploi, exécutable directement sur Bun/Node (sans dépendre de Cloudflare)
Ça pourrait aussi très bien convenir à une idée de projet que j’évalue en ce moment, surtout parce que la multi-tenance y est indispensable
Le mois dernier, j’avais regardé si je pouvais essayer LiveStore sur un projet perso, mais comme c’était une bêta preview, l’accès était difficile
J’espère pouvoir l’examiner plus en profondeur bientôt. C’est impressionnant de voir à quel point vous faites avancer activement les discussions sur le local-first
Quiconque a déjà construit une webapp avec sync hors ligne comprend immédiatement l’utilité d’un moteur de synchronisation
Excellente présentation aujourd’hui à la Local-First Conf
L’explication de l’architecture qui implémente l’event sourcing avec SQLite était claire et convaincante
Merci de promouvoir activement SQLite, en particulier OPFS Wasm SQLite, sur le web
PowerSync soutient lui aussi fortement SQLite, donc c’est réjouissant de voir un exemple de réussite comme LiveStore
Quand LiveStore étend son modèle d’event sourcing à l’échelle globale, il semble généralement synchroniser tous les clients via un backend central de synchronisation ; je me demande si c’est une exigence incontournable
Est-ce que des nœuds fédérés ou même un mode P2P complet seraient envisageables ? J’y pense aussi pour des cas d’usage de réseau social distribué
Je me demande si, combiné avec React et WASM, LiveStore pourrait remplacer le framework Juce utilisé par la plupart des applis musicales
Je suis beatmaker, et la combinaison Juce + C++ m’a toujours semblé difficile et intimidante. J’aimerais savoir si LiveStore pourrait être une bonne alternative pour quelqu’un qui veut se lancer dans le développement d’apps musicales
J’ai vu la présentation à la Local-first Conf, et il y a vraiment beaucoup de moteurs de synchronisation qui émergent en ce moment
LiveStore creuse en profondeur une zone intéressante à l’intersection de l’event sourcing et du moteur de sync
Je suis surpris de voir à quel point le système est déjà solide
Je l’ai utilisé moi-même ces dernières semaines sur un nouveau projet, et ça fonctionne de façon très fluide
Félicitations pour le lancement ! Je me demande si ce système correspond à la stratégie "1. Serialization" décrite ici
Comme cela est mentionné à propos de ProseMirror-collab, je voudrais savoir si LiveStore présente aussi le problème où les mises à jour de clients à faible latence finissent par bloquer celles de clients à forte latence
On dirait que LiveStore utilise wa-sqlite
J’aimerais en savoir plus sur la stratégie de persistance des données hors ligne : en particulier, est-ce que vous utilisez OPFS (avec une variante comme AccessHandlePoolVFS), IndexedDB, ou les deux ?
Je me demande aussi comment vous gérez l’instabilité d’OPFS selon les navigateurs et la politique de rétention sur 7 jours d’IndexedDB dans Safari
J’aimerais également savoir pourquoi vous avez choisi wa-sqlite alors que SQLite fournit désormais un build WASM officiel
J’ai brièvement présenté LiveStore récemment dans le podcast LocalFirst.fm (voir le lien https://www.localfirst.fm/24)
Le projet a l’air très prometteur, mais je suis aussi un peu prudent à l’idée de tomber dans le piège du hype
Je fais en parallèle une app local-first sur mesure et j’expérimente le support multi-appareil
Je me demande s’il serait possible d’ajouter en option du chiffrement E2E. D’après la documentation, on dirait qu’il suffirait d’ajouter du chiffrement au niveau du payload des événements ; à part la difficulté de compacter les logs côté serveur, cela semble presque faisable
Je construis moi-même LiveStore à partir des besoins qui sont apparus pendant mon travail sur Overtone
LiveStore comme Overtone sont conçus avec un objectif de pérennité à long terme. Le chiffrement E2E est déjà possible avec cette architecture
Je ne l’ai pas encore fait moi-même, mais je peux volontiers aider si quelqu’un rencontre des problèmes
Une possibilité serait aussi d’essayer la compaction des logs uniquement côté client. Je garderai clairement ce cas d’usage en tête dans le travail d’ingénierie
Je reste sceptique face à l’argument du support cross-platform, alors que la première chose montrée est l’absence de support web sur Android
Vous pouvez suivre l’avancement sur le GitHub officiel (https://github.com/livestorejs/livestore/issues/321)
J’espère que l’on comprend bien que, vu les différences de support des API web selon les plateformes, construire un système aussi ambitieux demande énormément d’efforts et de temps
Un détail intéressant dans la vidéo de démo : à 1 min 07, l’audio part sur la gauche. C’est mineur, mais je me suis dit que ce serait utile de le signaler
Je trouve impressionnant que vous fournissiez aussi des outils de développement ; on dirait que cela a été testé assez longtemps dans vos propres projets
Je me demande comment vous comptez gérer à long terme la compaction dans des applis/pages qui tournent longtemps, et aussi comment vous voyez la gestion du code à mesure que la couche applicative évolue, car l’event sourcing est élégant mais peut compliquer les choses (anciens clients, migrations de schéma, etc.)
Overtone semble prendre en charge plusieurs sources ; je me demande s’il proposera aussi la lecture hors ligne, surtout parce que l’interface de Spotify est pénible et qu’un remplaçant serait vraiment bienvenu
L’idée centrale est d’ajouter davantage d’informations sémantiques à chaque événement afin de pouvoir définir les recouvrements entre événements
Par exemple, dans une app de todo, un événement "todoCompleted" pour un même ID de tâche pourrait compacter les événements "todoCompleted" / "todoUncompleted" de cette tâche
Vous pouvez suivre l’avancement sur GitHub (https://github.com/livestorejs/livestore/issues/254)
L’event sourcing demande clairement de la discipline et de la conception. En matière de données, il n’y a pas de « repas gratuit » ; tout est affaire de compromis
Pour mes usages principaux, notamment Overtone, j’estime que les compromis de l’event sourcing sont plus intéressants
Il existe aussi plusieurs approches simples pour gérer le support des anciennes versions ; au final, cela dépend des caractéristiques et compromis propres à chaque application
Merci de vous intéresser à Overtone. J’ai moi aussi lancé ce projet par insatisfaction envers Spotify. Pour la lecture hors ligne, cela dépendra du fournisseur de musique
Par exemple, des albums possédés personnellement via Dropbox peuvent être pris en charge, mais pour des services de streaming comme Spotify, cela peut dépendre de leur politique
J’aime bien cette architecture, et surtout l’event sourcing
Mais l’event sourcing demande de l’attention : selon la vue voulue, la matérialisation (view materialization) peut être lente, et cela ralentit de plus en plus à mesure que les données grossissent
Pour résoudre cela, il faut gérer explicitement les mises à jour de matérialisation dans la transaction elle-même, par exemple avec des triggers
Il faut aussi y penser au moment de la réplication ou de la sync, et il est indispensable de bien connaître les concepts de CRDT pour la résolution de conflits
Ce serait formidable d’avoir une sorte de base de données proche de SQLite3 mais avec des fonctionnalités de langage Postgres, afin de pouvoir passer du local-first au remote-first simplement via la configuration
Sur le fond concernant le coût de matérialisation, nous allons continuer à améliorer la compaction, et l’ensemble de LiveStore est un framework conçu avec soin dans un objectif de performance optimisée