Você pode resolver isso sem um banco de dados, mas eu não o recomendaria. Basicamente, você tem pares (usuário, localStorage) e, quando um determinado usuário se identifica, seu localStorage deve ser fornecido de uma maneira. Você pode dizer aos usuários para armazenar seus armazenamentos locais em sua própria máquina, mas eles terão que copiá-los para outras máquinas, que exigem muito trabalho e nunca ganharão popularidade. Pode-se executar manualmente um pedaço de Javascript no console do navegador para garantir que o localStorage tenha seus dados e ter que copiar o localStorage nas máquinas é apenas um pouco mais fácil do que fazer manualmente a coisa toda.
Você pode colocar as informações localStorage codificadas em um URL, mas além do problema de tamanho do URL, que pode se tornar um problema e os problemas de codificação sempre presentes, todo o localStorage pode ser monitorado por terceiros, tendo acesso ao seu roteador. Eu sei que você disse que os dados não é sensível, mas eu acredito que você que não é sensível ainda . Porém, quando os usuários usarem isso, se for conveniente, eles também armazenarão dados confidenciais ou, seus clientes poderão ter essas tarefas para você ou até você perceberá que precisa armazenar dados lá que não sejam 100% públicos.
Além disso, na prática, você enfrentará problemas muito sérios de sincronização, ou seja, é ótimo tornar o localStorage independente de como será, mas qual é a versão real? Se você trabalha regularmente em 10 sessões diferentes, a sincronização do localStorages se torna um problema difícil. Isso significa que o localStorage precisa ser marcado com data e hora.
Portanto, você precisará de um local central, um servidor para armazenar a última versão localStorage salva. Se você for evitado pelos bancos de dados por alguns motivos desconhecidos, poderá armazenar localStorages em arquivos que identificam o usuário, como
johndoe.json
e, em seguida, você precisará implementar um recurso de exportação, que enviará o JSON atual do usuário ao servidor e o salvará em um arquivo e um recurso de importação, que fará o download do arquivo armazenado para o usuário e garantirá que localStorage seja atualizado adequadamente. Você pode fazer os dois juntos também, implementando uma sincronização.
Até agora, isso é simples, mas e se o usuário já tiver alguns dados úteis dentro de seu localStorage local e também no servidor? A abordagem mais simples é substituir uma pela outra, mas qual? Se estivermos importando, o local será substituído, se estiver exportando, o servidor será substituído, se sincronizarmos, o anterior será substituído.
No entanto, em alguns casos, você deseja mesclar duas localStorages do mesmo usuário, portanto:
novos elementos
Acredito que, se um elemento é novo, deve-se saber de alguma maneira que ele foi criado nesta sessão, o que é útil saber, porque isso significa que na outra sessão com a qual estamos nos fundindo, esse novo item não foi removido e, portanto, é intuitivo adicioná-lo.
mudanças de elemento
Se o mesmo elemento for diferente nos dois casos, a versão mais recente deverá prevalecer.
elementos removidos
O caso interessante é quando em uma sessão foi removido e na outra foi atualizado. Nesse caso, acho que a mudança mais recente deve prevalecer.
No entanto, apesar dos seus melhores esforços, os usuários ainda podem atrapalhar (e também o seu software), portanto, fazer backup de cada sessão no servidor faz sentido.