O cálculo local primeiro vs. RESTful
Então, vale a pena toda essa configuração e código moderno?
Se você estiver construindo um painel simples ou um aplicativo baseado em formulário, a abordagem tradicional da API JSON (REST ou GraphQL) ainda é a principal. Nesses modelos, o servidor é a única fonte da verdade e o cliente é apenas um terminal burro. É simples, sem estado e fácil de depurar. Também é familiar.
Mas essa simplicidade acarreta um custo de latência inevitável. Cada interação requer um ticket de ida e volta para o servidor. Se a rede falhar, seu aplicativo congela. As APIs JSON forçam você a gerenciar manualmente estados de carregamento, limites de erro e reversões de UI otimistas.
Local primeiro inverte o cálculo. Você paga antecipadamente um custo mais alto: precisa definir um esquema, gerenciar um banco de dados local e pensar em regras de sincronização. Mas, em troca, você obtém um aplicativo que parece um software nativo. O local primeiro cria continuidade de dados, a capacidade de sair do alcance do Wi-Fi, continuar trabalhando e fazer com que seus dados sigam você em todos os dispositivos quando você se reconectar.
Arquitetonicamente, usamos três componentes principais: o banco de dados, o mecanismo de sincronização e o cliente. Na verdade, isso é semelhante à sua pilha RESTful convencional. Na estrutura local-first, o mecanismo de sincronização substitui o servidor JSON API. Em suma, você tem uma quantidade semelhante de complexidade de alto nível, mas com diferentes atores no terreno.
A arquitetura local é um desenvolvimento fascinante para JavaScript e para a web em geral. Há uma enorme massa inercial de APIs JSON a ser superada, mas aqui está uma verdadeira contracorrente. O foco local pode nunca chegar ao nível de adoção da arquitetura RESTful, mas os dados locais e o SQL reativo constituem uma das tendências mais importantes a serem observadas de perto no momento.
