- Camada de dados para gerenciamento de estado projetada para permitir o desenvolvimento de aplicações de alto desempenho sem a carga de desenvolver a lógica de sincronização
- Tem como característica o uso de SQLite reativo e de um mecanismo de sincronização embutido
- Local-first, oferecendo alto desempenho mesmo offline, com suporte à sincronização automática quando a rede é restabelecida
- Todas as operações de gerenciamento de estado são executadas rapidamente sobre um banco de dados SQLite local
- Fluxos de dados reativos: quando os dados mudam, eventos são disparados imediatamente para os listeners conectados à UI, permitindo refletir mudanças de estado em tempo real
- Pode ser aplicado em diversos ambientes (web, mobile, desktop etc.)
- Em comparação com ferramentas de gerenciamento de estado existentes, oferece resultados superiores em desempenho nativo e consistência de dados
2 comentários
A demo na página principal ficou realmente muito bem feita. Depois de clicar e mexer um pouco na demo, dá até vontade de experimentar.
Comentários do Hacker News
Olá, sou cofundador da LiveStore (antes, criei a Prisma).
Acabei desenvolvendo a LiveStore para uso próprio enquanto passava os últimos 4 anos criando a Overtone, um cliente de música de alto desempenho com qualidade nativa.
A LiveStore adiciona uma camada reativa de sinais ao SQLite e a combina com uma sincronização baseada em event sourcing (semelhante ao Git)
Avaliei várias opções no ecossistema local-first, mas quase nenhuma resolve isso de forma tão elegante quanto a LiveStore
Há também o tinyBase como ferramenta com maturidade parecida, mas a arquitetura é diferente (CRDTs vs. event sourcing)
Tenho uma dúvida: por que limitar o volume de dados a 1 GB? Gostaria de saber se não seria possível ter uma opção para armazenar dados maiores no SQLite e mantê-los no disco
Não daria para mudar o modo de persistência apenas com uma configuração?
Multitenancy também me parece um cenário interessante. Em algo como o JIRA, cada organização exige um namespace separado, e seria ótimo se cada usuário pudesse receber apenas os tickets do seu time/departamento, em vez do conjunto inteiro
Basicamente, a estrutura seria um banco de dados local contendo um subconjunto dos dados totais. Seria incrível se viesse pronto um servidor de sincronização executável diretamente em Bun/Node (sem precisar de Cloudflare)
Parece combinar muito bem com uma ideia de projeto que estou avaliando agora, especialmente porque multitenancy é indispensável
No mês passado, fui ver se usaria a LiveStore em um projeto de hobby, mas como ainda era uma preview beta, o acesso era difícil
Espero poder olhar mais a fundo em breve. É impressionante ver vocês liderando ativamente a discussão sobre local-first
Quem já criou uma webapp com sincronização offline percebe de imediato a utilidade de um motor de sync
Gostei muito da apresentação de hoje na Local-First Conf
A explicação da arquitetura de implementar event sourcing com SQLite foi clara e convincente
Obrigado por divulgar o SQLite de forma tão forte na web, especialmente o OPFS Wasm SQLite
A PowerSync também apoia fortemente o SQLite, então é muito bom ver um caso de sucesso como a LiveStore
Quando a LiveStore escala globalmente o modelo de event sourcing, normalmente ela sincroniza todos os clientes por meio de um backend central de sync. Queria saber se isso é um requisito obrigatório
Também gostaria de perguntar se nós federados (federated nodes) ou até um modo P2P completo seriam possíveis. Estou considerando a aplicação disso em casos como redes sociais distribuídas
Tenho curiosidade se, em combinação com React e WASM, a LiveStore poderia substituir o framework Juce que a maioria dos apps de música usa
Sou beatmaker, e a combinação de Juce com C++ sempre pareceu difícil e intimidadora. Queria saber se a LiveStore poderia ser uma boa alternativa para quem quer entrar no desenvolvimento de apps musicais
Vi a apresentação na Local-first Conf e hoje em dia estão surgindo muitos motores de sync diferentes
A LiveStore está explorando a fundo uma área interessante, combinando event sourcing e motor de sync
Fiquei surpreso com o quanto isso já se tornou um sistema robusto
Nas últimas semanas usei isso diretamente em um projeto novo e está funcionando de forma realmente fluida
Parabéns pelo lançamento! Fiquei curioso se esse sistema se encaixa na estratégia "1. Serialization" descrita aqui
Gostaria de saber se, como foi mencionado no ProseMirror-collab, a questão de clientes de baixa latência com atualizações frequentes bloquearem as atualizações de clientes com alta latência também aparece na LiveStore
Parece que a LiveStore usa wa-sqlite
Gostaria de ouvir mais detalhes sobre a estratégia de persistência offline dos dados. Especificamente, queria saber se usam OPFS (incluindo variantes como AccessHandlePoolVFS), IndexedDB, ou ambos
Também queria saber como estão lidando com a instabilidade do OPFS entre navegadores e com a política de retenção de 7 dias do IndexedDB no Safari
Também gostaria de entender por que escolheram wa-sqlite mesmo existindo um build WASM oficial do SQLite
Recentemente apresentei brevemente a LiveStore no podcast LocalFirst.fm (veja o link https://www.localfirst.fm/24)
Parece um projeto muito promissor, mas também fico um pouco cauteloso para não cair numa armadilha de hype
Estou experimentando suporte a múltiplos dispositivos enquanto construo um app local-first parecido sob medida
Queria saber se também seria possível adicionar criptografia E2E de forma opcional. Pela documentação, parece que quase daria para adicionar criptografia no nível do payload do evento; a única dificuldade maior seria a compactação dos logs no servidor
Estou criando a LiveStore diretamente a partir das necessidades que surgiram enquanto trabalhava na Overtone
Tanto a LiveStore quanto a Overtone estão sendo feitas com foco em sustentabilidade de longo prazo. A criptografia E2E é uma estrutura que já pode ser implementada
Eu mesmo ainda não fiz isso, mas posso ajudar sempre que houver problemas
Tentar fazer compactação de log apenas no lado do cliente também pode ser uma abordagem. Vou manter esse caso de uso em mente durante a engenharia
Sou cético quanto à alegação de suporte cross-platform, já que a primeira coisa mostrada foi a falta de suporte à web no Android
É possível acompanhar o andamento no GitHub oficial (https://github.com/livestorejs/livestore/issues/321)
Espero que entendam que, como o suporte a APIs web varia entre plataformas, criar um sistema ambicioso como este exige muito esforço e tempo
Um detalhe interessante no vídeo de demonstração: em 1 minuto e 7 segundos, o áudio puxa para a esquerda. É algo pequeno, mas achei útil avisar
É impressionante que vocês também ofereçam ferramentas de desenvolvedor; parece algo testado por bastante tempo em um projeto próprio
Minha dúvida é como pretendem lidar, no longo prazo, com a compactação em apps/páginas que ficam em execução por muito tempo, e também que, embora event sourcing seja um conceito excelente, conforme a camada da aplicação evolui a manutenção do código (clientes antigos, migração de schema etc.) pode ficar difícil
A Overtone parece oferecer suporte a várias fontes; queria saber se também vai oferecer reprodução offline, principalmente porque a UI do Spotify é desconfortável e eu realmente preciso de uma alternativa
A ideia central é atribuir mais informação semântica a cada evento, para podermos definir sobreposição entre eventos
Por exemplo, em um app de tarefas, um evento "todoCompleted" para um mesmo ID de tarefa pode compactar eventos "todoCompleted"/"todoUncompleted" daquela tarefa
Dá para acompanhar o andamento no GitHub (https://github.com/livestorejs/livestore/issues/254)
Event sourcing realmente exige disciplina e design. Não existe "almoço grátis" quando se trata de dados, então o essencial são os trade-offs
Nos meus principais casos de uso, como a Overtone, sinto que os trade-offs do event sourcing valem mais a pena
Existem várias formas simples de oferecer suporte a versões antigas; no fim, isso depende das características e trade-offs de cada aplicação
Obrigado pelo interesse na Overtone. Eu também comecei esse projeto por insatisfação com o Spotify. No caso da reprodução offline, isso depende da fonte de áudio
Por exemplo, é possível dar suporte a álbuns que a pessoa possui em serviços como Dropbox, mas serviços de streaming como Spotify podem variar de acordo com a política
Gosto dessa arquitetura, especialmente do event sourcing
Mas é preciso ter cuidado com event sourcing. Dependendo da view desejada, a materialização (view materialization) pode ser lenta, e isso piora conforme os dados crescem
A solução para isso é gerenciar diretamente, dentro da transação, a atualização da materialização com gatilhos e mecanismos parecidos
Também é algo a considerar na replicação ou sincronização, e no caso de resolução de conflitos é importante conhecer bem os conceitos de CRDT
Seria ótimo existir algo como um banco parecido com SQLite3 com recursos de linguagem do Postgres, para poder alternar entre local-first e remote-first só mudando configuração
Quanto ao ponto principal sobre o custo de materialização, a compactação ainda vai melhorar bastante, e toda a LiveStore é um framework cuidadosamente projetado com foco em otimização de desempenho