- Capa de datos para gestión de estado diseñada para permitir el desarrollo de aplicaciones de alto rendimiento sin la carga de desarrollar lógica de sincronización
- Se caracteriza por usar SQLite reactivo y un motor de sincronización integrado
- Local-first: ofrece alto rendimiento incluso sin conexión y admite sincronización automática cuando se restablece la red
- Todas las operaciones de gestión de estado se realizan rápidamente sobre una base de datos SQLite local
- Flujos de datos reactivos: cuando cambian los datos, se generan eventos de inmediato para los listeners conectados a la UI, lo que permite reflejar los cambios de estado en tiempo real
- Puede aplicarse en diversos entornos (web, móvil, escritorio, etc.)
- En comparación con las herramientas de gestión de estado existentes, ofrece mejores resultados en rendimiento nativo y consistencia de datos
2 comentarios
La demo en la página principal está realmente muy bien hecha. Después de darle clic un rato a la demo, dan ganas de probarlo.
Comentarios en Hacker News
Hola, soy cofundador de LiveStore (antes hice Prisma).
Terminé desarrollando LiveStore para usarlo yo mismo mientras construía Overtone, un cliente de música de alto rendimiento con calidad nativa, durante los últimos 4 años.
LiveStore agrega una capa de señales reactiva sobre SQLite y la combina con una sincronización basada en event sourcing (similar a Git).
He evaluado muchas opciones de local-first y casi ninguna lo resuelve tan limpiamente como LiveStore.
Como herramienta similar en nivel de madurez también está tinyBase, pero su estructura es distinta (CRDTs vs. event sourcing).
Tengo curiosidad por saber por qué limitaron el volumen de datos a 1 GB, y si no podrían ofrecer una opción para guardar datos más grandes en SQLite y mantenerlos en disco.
¿No sería posible cambiar el modo de persistencia simplemente con una configuración?
La multitenencia también me parece un escenario interesante: cuando, como en JIRA, cada organización necesita un namespace separado, estaría bueno que cada usuario recibiera solo los tickets de su equipo o departamento, no todos.
Básicamente sería una estructura donde la base de datos local es un subconjunto de todos los datos. Si viniera en la caja un servidor de sincronización ejecutable directamente en Bun/Node (sin necesidad de Cloudflare), estaría increíble.
También parece encajar muy bien con una idea de proyecto que estoy evaluando ahora mismo, especialmente porque la multitenencia es indispensable.
El mes pasado revisé LiveStore para ver si podía usarlo en un proyecto personal, pero como era una beta preview, el acceso era difícil.
Ojalá pronto pueda explorarla más a fondo. Me impresionó ver que están impulsando activamente la conversación alrededor de local-first.
Cualquiera que haya creado una webapp con sincronización offline entiende de inmediato lo útil que es un motor de sync.
Hoy vi su charla en Local-First Conf y estuvo muy buena.
La explicación de la estructura para implementar event sourcing con SQLite fue clara y convincente.
Gracias por promocionar activamente SQLite, especialmente OPFS Wasm SQLite, en la web.
En PowerSync también apoyamos fuertemente a SQLite, así que da gusto ver un caso exitoso como LiveStore.
Cuando LiveStore escala globalmente su modelo de event sourcing, normalmente sincroniza a todos los clientes usando un backend central de sync. Me pregunto si eso es un requisito obligatorio.
Quisiera saber si también serían posibles nodos federados (federated nodes) o un modo P2P completo. También estoy considerando aplicarlo a casos como redes sociales distribuidas.
Me pregunto si, combinado con React y WASM, LiveStore podría reemplazar al framework Juce que usan la mayoría de las apps de música.
Soy beatmaker, y la combinación de Juce con C++ siempre me ha parecido difícil e intimidante. Quisiera saber si LiveStore podría ser una buena alternativa para quienes quieren entrar al desarrollo de apps musicales.
Vi la charla en Local-first Conf, y últimamente están apareciendo muchísimos motores de sync.
LiveStore está profundizando en un espacio muy interesante que combina event sourcing y motor de sincronización.
Me sorprendió que ya se haya convertido en un sistema tan sólido.
Lo probé directamente en un proyecto nuevo durante las últimas semanas, y la verdad es que funciona muy fluido.
¡Felicidades por el lanzamiento! Me pregunto si este sistema encaja con la estrategia de "1. Serialization" descrita aquí.
Como se menciona en ProseMirror-collab, quisiera saber si en LiveStore también aparece el problema de que las actualizaciones de clientes de baja latencia que actualizan con frecuencia bloqueen las de clientes con alta latencia.
Parece que LiveStore usa wa-sqlite.
Me gustaría conocer más en detalle su estrategia de persistencia de datos offline. En concreto, tengo curiosidad por saber si usan OPFS (incluyendo variantes como AccessHandlePoolVFS), IndexedDB, o ambos.
También quisiera saber cómo manejan la inestabilidad de OPFS entre navegadores y la política de retención de 7 días de IndexedDB en Safari.
Quisiera entender por qué eligieron wa-sqlite cuando SQLite ya ofrece un build oficial de WASM.
Hace poco mencioné brevemente a LiveStore en el podcast LocalFirst.fm (ver enlace: https://www.localfirst.fm/24).
Parece un proyecto muy prometedor, aunque también me da un poco de cautela que pueda caer en una trampa de hype.
Yo también estoy experimentando con soporte multidispositivo mientras construyo de forma personalizada una app local-first similar.
Me pregunto si sería posible agregar cifrado E2E de forma opcional. Por la documentación, parece que bastaría con añadir cifrado a nivel de payload del evento; salvo por la dificultad de comprimir logs en el servidor, suena bastante viable.
Estoy creando LiveStore directamente a partir de necesidades que surgieron mientras trabajaba en Overtone.
Tanto LiveStore como Overtone están siendo construidos con la mira en la sostenibilidad a largo plazo. El cifrado E2E es una estructura que ya se puede implementar.
Yo no lo he probado personalmente, pero si surge algún problema, con gusto puedo ayudar.
También podría ser una opción intentar la compactación del log solo del lado del cliente. Sin duda voy a tener este caso de uso muy presente mientras seguimos haciendo ingeniería.
Soy escéptico con la afirmación de soporte multiplataforma, cuando lo primero que muestran es que no funciona en Android web.
El avance puede seguirse en el GitHub oficial (https://github.com/livestorejs/livestore/issues/321).
Esperamos que se entienda que, debido a que el soporte de las web APIs varía entre plataformas, construir un sistema ambicioso como este requiere muchísimo esfuerzo y tiempo.
Un detalle interesante del video demo: en el minuto 1:07 el audio se va hacia la izquierda. Es algo menor, pero pensé que valía la pena comentarlo.
Me parece muy bueno que también ofrezcan herramientas para desarrolladores; da la impresión de que lo han estado probando por bastante tiempo en proyectos propios.
Tengo curiosidad por saber cómo piensan manejar la compactación en apps/páginas que corren a largo plazo, y también que, aunque event sourcing es un concepto genial, a medida que evoluciona la capa de aplicación puede volverse más difícil la gestión del código (clientes antiguos, migraciones de esquema, etc.).
Parece que Overtone soporta varias fuentes; me pregunto si también ofrecerá reproducción offline, especialmente porque la UI de Spotify me resulta tan incómoda que necesito urgentemente una alternativa.
La idea principal es dar a cada evento más información semántica, para poder definir la superposición entre eventos.
Por ejemplo, en una app de tareas, un evento
todoCompletedpara un mismo ID de tarea podría compactar los eventostodoCompleted/todoUncompletedde esa tarea.El avance puede seguirse en GitHub (https://github.com/livestorejs/livestore/issues/254).
Sin duda, en event sourcing la disciplina y el diseño son importantes. En datos no existe el "almuerzo gratis", así que los trade-offs son la clave.
En mis casos de uso principales, como Overtone, siento que los trade-offs de event sourcing son mejores.
Para cosas como soporte a versiones antiguas, existen varias formas sencillas de resolverlo; al final depende de las características y trade-offs de cada aplicación.
Gracias por interesarte en Overtone. Yo también empecé este proyecto por mi insatisfacción con Spotify. En cuanto a la reproducción offline, depende de la fuente de audio.
Por ejemplo, sí podría soportarse para álbumes propios almacenados en Dropbox, pero en servicios de streaming como Spotify puede depender de la política del proveedor.
Me gusta esta arquitectura, especialmente el event sourcing.
Pero hay que tener cuidado con event sourcing: según la vista que quieras, la materialización (view materialization) puede ser lenta, y cuanto más crecen los datos, peor se pone.
La solución a esto es gestionar directamente la actualización de materializaciones dentro de la transacción, por ejemplo con triggers.
También hay que tenerlo en cuenta al replicar o sincronizar, y en cuanto a resolución de conflictos, definitivamente conviene conocer los conceptos de CRDT.
Sería genial tener una base de datos parecida a SQLite3 pero con capacidades del lenguaje de Postgres, para poder usar local-first y remote-first simplemente cambiando configuraciones.
En cuanto al punto principal sobre el costo de materialización, vamos a seguir mejorando la compactación, y todo LiveStore es un framework diseñado cuidadosamente con el objetivo de optimizar el rendimiento.