E se “serverless” significasse nenhum servidor de backend?
Um post propondo apps web “serverfree” — em que toda a lógica e os dados vivem inteiramente no dispositivo do usuário — provoca comparações com software de desktop clássico, bundles no estilo Electron e o movimento mais amplo “local-first”. Os comentários ponderam o apelo de privacidade, capacidade offline e faturamento mais simples contra problemas práticos como sincronização entre dispositivos, backups, resolução de conflitos e atualizações, muitas vezes concluindo que alguma forma de sync opcional em nuvem ou ponto a ponto ainda é necessária. Muitos também criticam o rótulo “serverfree” como confuso, observando que hospedagem estática ainda é necessária e que ideias semelhantes vêm sendo exploradas há anos sob outros nomes.
Âmbito de “serverless” / “serverfree”
- Muitos leem “serverless” como abreviação de faturamento por invocação, no estilo Lambda; alguns argumentam que isso é apenas hospedagem compartilhada com nova marca.
- Vários não gostam de “serverfree” como termo porque um host estático ainda é um servidor e os “servidores” lógicos de “app/database” ainda existem, apenas movidos para o lado do cliente.
- Alguns preferem “local-first” por ser mais claro: primeiro o dispositivo, servidor opcional, em vez de “offline-first” ou “serverfree”, que soam mais limitantes.
“Isso não é só um app de desktop / Electron?”
- Vários comentários dizem que a proposta, em grande parte, recria aplicativos de desktop, ou empacotamento no estilo Electron, mas via navegador + SQLite em WASM.
- Críticos observam que demos uma volta para stacks pesadas e mais lentas a fim de recuperar capacidades que os apps de desktop já tinham.
- Os defensores respondem que a distribuição pela web (“acesse esta URL, sem instalação, sem app store, sem assinatura de código”) é uma grande vantagem prática.
Armazenamento de dados, backup e sincronização
- Modelo central: os dados vivem inteiramente no dispositivo local (por exemplo, SQLite no navegador + OPFS).
- Preocupações:
- Não há sincronização integrada entre dispositivos; usuários muitas vezes dependem de 3–4 dispositivos e esperam compartilhamento sem atrito.
- Risco de perda de dados por falha/roubo do dispositivo; exportação/importação manual é vista como um “beco sem saída de usabilidade”.
- Mitigações sugeridas:
- Usar armazenamento em nuvem genérico (Dropbox/Nextcloud/iCloud/etc.) para sincronizar arquivos locais, opcionalmente criptografados.
- Sincronização criptografada opcional com um servidor central, ou sincronização ponto a ponto (WebRTC, Bluetooth, LAN, protocolos P2P).
- Distinguir entre armazenamento “burro” e lógica de resolução de conflitos específica da aplicação.
Tecnologias local-first / sync
- A ideia se alinha ao “software local-first”: armazenamento principal no dispositivo, sync como complemento.
- Comentadores mencionam ferramentas emergentes (por exemplo, sistemas baseados em CRDT, camadas de sync para SQLite, protocolos alternativos de sincronização) e mantêm listas comparativas.
- Há interesse em sincronização genérica no nível do sistema operacional, mas também reconhecimento de que a resolução de conflitos muitas vezes é específica da aplicação e complexa.
Questões de implementação
- Foram levantadas dúvidas sobre:
- Como SQLite+WASM+OPFS se compara ao localStorage em desempenho e durabilidade.
- O overhead e o benefício de usar um web worker que imita HTTP para uma DB local versus acesso direto à DB.
- Migrações de esquema e mudanças incompatíveis em uma DB puramente no lado do cliente.
- A praticidade de evitar qualquer backend quando há chaves de API ou serviços de terceiros envolvidos.
Sentimento geral
- Muitos acham o experimento intelectualmente interessante e alinhado com objetivos de privacidade/controle local.
- Ainda há ceticismo significativo em relação à terminologia, à falta de sync/backup, à robustez operacional e a se isso realmente melhora apps de desktop bem projetados ou apps híbridos local+cloud.