Pare de construir bancos de dados

A complexidade da gestão de dados

• Engenheiros de frontend acabam percebendo a necessidade de armazenar em cache os dados da API.
• No começo, tudo começa com um armazenamento simples de dados, mas, à medida que os pedidos de funcionalidades aumentam, acabam implementando cache de dados, índices manuais, mutações otimistas (optimistic mutations), invalidação recursiva de cache e assim por diante.
• Esses recursos se parecem com o funcionamento interno de um banco de dados e, em aplicações frontend complexas, no fim das contas você acaba criando um banco de dados especializado no domínio.

O básico do cache

• Tudo começa salvando o resultado de uma requisição de API em uma variável local.
• Em aplicações web que usam frameworks declarativos, os dados são guardados em variáveis para evitar requisições desnecessárias à API.
• O passo seguinte é mover o cache para uma camada mais alta ou para fora da árvore de UI.

Ganho de velocidade com índices

• Ao organizar os dados de uma forma específica, é possível reduzir o trabalho da aplicação e melhorar a experiência do usuário.
• Percebe-se que a otimização de dados no frontend é parecida com o funcionamento interno do armazenamento de um banco de dados.
• A estrutura de dados é aprimorada ao armazenar dados por ID e criar índices que permitem consultar itens rapidamente por data.

Mutações otimistas

• Consiste em simular localmente o efeito de uma determinada ação sem esperar a resposta do servidor.
• Isso faz parecer que a interface do usuário responde imediatamente, mas, se o resultado no servidor for diferente, a UI precisa reverter a alteração.
• Há desafios como duplicar a lógica entre cliente e servidor, lidar com erros assíncronos e reconciliar alterações mesmo após reinicializações da aplicação.

Invalidação recursiva de cache

• Os dados aparecem em vários pontos do cache, e é necessário invalidá-lo corretamente após atualizações para manter a consistência com o servidor.
• A UI precisa saber quais partes do cache estão relacionadas a cada mutação, e isso pode se tornar frágil à medida que o sistema cresce.
• Quando combinado com mutações otimistas, fica ainda mais difícil duplicar a lógica do servidor no cliente para prever mudanças no servidor.

Está construindo um banco de dados?

• Em aplicações frontend com complexidade suficiente, você inevitavelmente acaba construindo muitos recursos de gestão de dados, o que tira tempo de agradar os usuários e resolver problemas de negócio.
• O texto propõe uma alternativa na forma de uma stack de banco de dados otimizada para frontend.

Apresentando o SQLSync

• Foi desenvolvido o SQLSync, uma stack de banco de dados otimizada para frontend baseada em SQLite.
• O SQLSync foi projetado para resolver problemas de gestão de dados e permitir que desenvolvedores foquem nas funcionalidades únicas da aplicação.
• O SQLSync oferece cache durável, todos os recursos do SQLite, mutações otimistas, invalidação inteligente de cache e consultas reativas.

Opinião do GN⁺

O ponto mais importante deste texto é o fenômeno de que, à medida que a complexidade das aplicações frontend aumenta, desenvolvedores acabam implementando por conta própria recursos parecidos com os de um banco de dados. Esse trabalho consome tempo dos desenvolvedores e os afasta da criação de funcionalidades que realmente entregam valor aos usuários. Stacks de banco de dados otimizadas para frontend, como o SQLSync, apresentam uma abordagem inovadora para resolver esse problema. O motivo pelo qual este texto é interessante é que ele aponta um problema fundamental nos métodos tradicionais de gestão de dados e busca uma nova solução para que desenvolvedores possam trabalhar de forma mais eficiente.

[GN⁺]

Opinião do Hacker News

• Entendimento sobre o amigo criador do projeto

  • SQLsync é uma ferramenta que permite que desenvolvedores front-end consultem e atualizem bancos de dados remotos dentro do navegador.
  • Funciona usando o poder do WASM para transferir um banco de dados SQLite para o navegador.
  • Usa um algoritmo reativo para sincronização entre vários clientes.
  • É uma abordagem inovadora para resolver o trabalho de sincronização de dados dos desenvolvedores.

• Experiência com software de gerenciamento de projetos em uma empresa anterior

  • Os dados eram sincronizados com um mecanismo de check-in/check-out, mas isso passou a ser visto como ultrapassado com o surgimento de apps com atualizações em tempo real.
  • Com 10 anos de experiência construindo apps web SPA, isso parece ter sido um mecanismo de sincronização de dados à frente do seu tempo.

• Problemas que desaparecem ao abandonar SPAs

  • Ao usar soluções como Hotwire ou htmx, as consultas ao servidor ficam mais simples, e o problema de torná-las rápidas é melhor compreendido.

• Opinião do criador do SQLSync

  • Ele está respondendo muitas perguntas e pretende verificar periodicamente as que tiver perdido.
  • Está feliz com a discussão no primeiro post, focado na motivação para criar o SQLSync.
  • No próximo post, pretende explicar como o SQLSync funciona.

• Não dar aos usuários um modelo mental diferente da realidade

  • A sincronização de banco de dados pode ser mais complexa do que o modelo cliente-servidor.
  • Quando é necessária uma UI rápida, parece mais seguro usar primitivas de CRDT.

• O princípio de que o que é mensurável é gerenciado e a falácia do custo afundado

  • A complexidade do banco de dados é o problema.
  • A sintaxe do SQL é o problema e, se usar um banco de dados relacional básico fosse uma experiência agradável, haveria mais tentação de usar um DB em vez de criar um banco de dados próprio.
  • Bons bancos de dados usam SQL e, para eficiência, é preciso usar a linguagem do banco de dados.

• O problema da sincronização de estado entre cliente e servidor

  • Voltar ao modelo PHP/SSR pode contornar o problema à custa da UX.
  • SPA é bom, mas o envio de formulários multipart ainda funciona.
  • Manter todo o estado no servidor e tratar o cliente como um terminal simples melhora a experiência de desenvolvimento.

• Comparação com bibliotecas ORM

  • Pergunta comparando o SQLsync com o uso direto de TypeORM e SQL.js com suporte no navegador.

• Diferença entre bancos de dados de front-end e back-end

  • Um banco de dados de front-end pode ser diferente do back-end, e pode haver necessidade de gerenciar melhor o estado em tempo real no cliente.
  • Está considerando usar react query e WebSockets para lidar com invalidação de cache.
  • A ideia do SQLsync também vale consideração.

• Tentativa semelhante com o SignalDB

  • O SignalDB usa reatividade baseada em sinais e uma sintaxe de consulta semelhante ao MongoDB, independente de framework.