Pushpin: Suporte de navegador

Oh, eu sou totalmente a favor do suporte do navegador! Acho que poderíamos executar o front-end no navegador e o back-end em um processo de nó.

Dito isso - o front-end é apenas um thread de renderização. Você precisa ter um back-end presente com um front-end o tempo todo para realmente fazer algo interessante. Acho que poderíamos imaginar um ... mid-end que seria mais próximo do que você está procurando Gozala e terceirizar mais responsabilidade para um back-end compartilhado.

Dito isso, é uma meta de engenharia explícita (mas possivelmente mutável) para este projeto que seja independente. Nenhum serviço externo é necessário para que ele funcione. Nada mais para instalar ou confiar.

Para ser mais específico, estou pensando em peças de back-end que fornecem recursos de rede e sistema de arquivos. Idealmente, o front-end deve ser capaz de persistir as alterações no cache do front-end se o back-end estiver inativo.

Existe algum motivo pelo qual as alterações locais / offline não puderam ser persistidas no front-end e replicadas para o back-end quando estiverem disponíveis? Isso é diferente da complexidade da implementação, obviamente.

Bem, persistir as coisas é o trabalho do back-end. É isso que estou tentando dizer. O front-end é um único thread de renderização que não persiste. Esta é uma propriedade importante e essencial do front-end. Se você quiser ter uma espécie de mid-end que faça persistência local e possa operar sem o back-end, por que não torná-lo um peer completo?

A razão pela qual o front-end não faz nenhuma persistência é porque a persistência, o cálculo CRDT e tudo o mais bloqueia o thread de entrada.

Bem, persistir as coisas é o trabalho do back-end. É isso que estou tentando dizer. O front-end é um único thread de renderização que não persiste. Esta é uma propriedade importante e essencial do front-end. Se você quiser ter uma espécie de mid-end que faça persistência local e possa operar sem o back-end, por que não torná-lo um peer completo?

Tudo bem, estou disposto a adotar uma terminologia intermediária. No entanto, não tenho certeza do que "par completo" significa neste contexto.

A razão pela qual o front-end não faz nenhuma persistência é porque a persistência, o cálculo CRDT e tudo o mais bloqueia o thread de entrada.

Os navegadores já tinham threads de trabalho há algum tempo. Eles são adequados para esse tipo de coisa, de fato, com os service workers, você pode até mesmo executar todas as coisas enquanto está totalmente fora da grade e com o processo de back-end fora do intervalo.

Sim, eu adoraria mover o trabalhador de "segundo plano" para um trabalhador de serviço e fazer o pino funcionar como um PWA. Esse é o sonho!

Para o trabalhador, você pode fazer persistência de longo prazo no navegador com algo como o IndexDB integrado ou soluções de armazenamento "nativo do navegador" semelhantes, embora haja algumas ressalvas importantes. Alguém está trabalhando nisso atualmente?