Persistência dos dados

[filipedeschamps]

Isso é uma coisa interessante para resolver, pois tem várias abordagens dependendo de como o projeto vai crescer, por exemplo:

Abordagem 1

Cada sub projeto (tipo consulta de cep) tem sua própria tabela para guardar os ceps.

Abordagem 2

Uma única tabela genérica de cache, que possui uma chave, a informação que deve ser guardada (em JSON) e uma outra coluna para tempo de expiração.

E estamos bastante dispostos a testar o FaubaDB.

[filipedeschamps]

Tutorial para gerenciar os secrets:
https://www.leighhalliday.com/secrets-env-vars-nextjs-now

[eedsilva]

Seria massa ter esse tipo de informacao de forma descentralizada. Talvez blockchain se encaixaria bem para persistencia de dados.

[filipedeschamps]

@eedsilva interessante! Você poderia esclarecer um pouco mais essa idéia?

[eedsilva]

Opa! Com certeza.

Entao, eu to partindo da ideia aonde os dados sao inacessiveis por causa de uma "limitacao" colocada por quem gerencia/ou que tenha propriedade dos dados. Isso eh possivel simplismente porque eles podem fazer isso e ninguem tem o direito de reclamar.
A ideia que voces estao propondo eh massa, mas tem o mesmo principio tecnico que a dos Correrios que eh uma base de dados centralizada ou seja, uma existe uma entidade tomando conta.

Se a ideia eh tornar esses dados publicos e talvez tendo a comunidade ajudando a gerar mais dados, porque nao usar um sistema descentralizado, validado, com logs e de livre acesso (to fetch data)?
Tendo um simples smart contract live em algum blockchain 3.0 (posso entrar com mais detalhes sobre isso em algum outro post caso interesse) ja resolveria esse problema de persistencia de dados e talvez ate do cache.

[eedsilva]

Tenho minhas preferencias por qual blockchain utilizar, mas porque nao tambem ser blockchain agnostico e descentralizar de verdade com mais liberdade para os devs? :)

[filipedeschamps]

Show @eedsilva ! Eu conheço muito pouco de blockchain aplicado para isso, se puder me educar no assunto ficaria muito feliz. Entendo ainda menos sobre "smart contract live" e "blockchain 3.0", e como ficaria para atualizar um dado e como distribuir ele de fato.

Minha escolha inicial do FaunaDB veio até da própria sugestão do criador do Next.js, principalmente porque o banco promete se distribuir em várias regiões automagicamente mas claro, mantendo um controle central.

[eedsilva]

Eu posso resumir um basicao do que eh Blockchain 1.0 , 2.0 e 3.0.
Basicamente 1.0 eh consensus algorithm do bitcoin. Entao nao existe nada alem de transferencia e validacao de uma moeda do cliente A para o B.

2.0: Seguindo o mesmo algoritmo, mas agora com uma VM built in no software de instalacao do node. Essa foi a grande sacada do Ethereum que tendo essa VM pra rodar codigo escrito em Solidity que sao os tao falados smart contracts fez a brincadeira ir para um outro nivel. E a partir desse novo boom agora uma pessoa pode executar alguma acao de algum contrato num blockchain.
Em outras palavras, eh basicamente voce tendo uma API aberta aonde voce pode fazer um ping e aquilo pode fazer um get, post, put ou delete dependendo do que foi escrito no smart contract.
Solidity eh uma linguagem de programacao que lembra um pouco JS.

Porem, mesmo com toda essa inovacao de ter uma VM que roda codigo e tudo mais, uma transacao num blockchain com esse algoritmo (PoW) eh muito caro, lento e requer muito recurso dos mineradores para fazer a validacao.

Dai vem o 3.0 aonde transacoes sao rapidas, e o usuario paga pelo que ta realmente usando. Mas ai existe um outro tipo de algoritmo para fazer essas validacoes das transacoes que eh chamado de DPoS.

Existe tambem o PoS que promete eficiencia, mas eu nao tenho muito conhecimento pra falar. Acredito que o Ethereum vem tentando implementar ele da melhor maneira possivel.

Tem muito conteudo ainda pra ser explicado tipo como fazer a comunicacao de um usuario com o blockahin etc. Mas ai vai uma pequena introducao pra esse mundo e que eh bem possivel ter os dados num blockchain e completamente descentralizado

[filipedeschamps]

Sensacional @eedsilva obrigado pelo norte! Por hora vou fechar a issue para de início tentar deixar a API o mais "stateless" o possível, colocar o foco em solidificar essa camada agora, para depois em seguida retomar a camada de persistência e dai eu reabro a issue 👍