Substituir `github.com/go-pg/pg`

[cuducos]

Atualmente o projedo depende do go-pg, mas esse projeto diz no README.md:

go-pg is in a maintenance mode and only critical issues are addressed. New development happens in Bun repo which offers similar functionality but works with PostgreSQL, MySQL, MariaDB, and SQLite.

https://github.com/uptrace/bun

Talvez seja remover essa dependência que agora é minimamente mantida.

Algumas alternativas:

Usar o Bun

Prós: provavelmente API semelhante, compatibilidade com outros bancos de dados

Contra: como usamos arquivos .sql (ou seja, queries customizadas) ao invés do ORM, a sintaxe do PostgreSQL (que temos agora) pode não ser compateivel com os outros bancos — especialmente pensando nas possibilidades, no potencial que temos com JSON no PostgreSQL

Usar apenas um drive de PostgreSQL

Prós: KISS, remoção de um ORM que não utilizamos

Contrta: talvez teremos que lidar com conexão do banco de dados de uma forma mais explícita

[avelino]

A pergunta que faço é: você pensa em usar outro banco de dados ou tudo que esta desenvolvendo é e será para trabalhar com Postgres?

Caso a resposta seja sim, colocaria outra pergunta: por quê?

Gosto de software/lib especialista em uma tecnologia, ao ser agnóstico nunca seremos o melhor em todos e sim atenderemos todos, vulgo vendedor de sorvete — o vendedor de sorvete quer agradar todo mundo. No passado queria que o prestd tivesse suporte a ~ANY~ tipo de banco de dados (postgres, mysql e etc), nessa thread discutimos sobre isso e resolvemos ser especialista em Postgres (fazer o mais bem feito possível em nosso domínio).

Nessa thread falamos um pouco sobre a possível troca da lib/pg por pgx, pode ser que ajude. https://github.com/prest/prest/issues/246#issuecomment-907236040

[cuducos]

Excelente ponto, @avelino.

Depois de umas duas semanas refletindo, acho que o que consigo organizar em termos de prioridade é o seguinte:

1. Alta prioridade: oferecer uma API web para consulta de CNPJ
2. Prioridade média: oferecer um pacote que facilite o acesso aos dados de CNPJ

Na prática, como eu vejo essas priordades impactando nas decisões do projeto:

Alta prioridade

Considerando: a. a estrutura existente b. meu (mantenedor) conhecimento em infra e c. estratégias de limitação/redução de custos para produção

Ainda acho que o ETL em Go, banco de dados em PostgreSQL (excelente performance sem muita configuração) e API web em Go (alta disponibilidade) ainda é o melhor caminho.

Então o foco é, de fato, o fluxo download, PostgreSQL, web.

Prioridade média

Para facilitar o acesso aos dados, o ETL pode ter opções de exportar os dados: por exemplo, gerar um CSV único, ou… como sugeri, alimentar um MongoDB. Isso não seria nem a prioridade mais alta do projeto, e nem utilizado em produção — seria apenas um “extra” oferecido para a comunidade de dados abertos.

---

Dito isso, ainda não decidi sobre Bun ou apenas um drive do PostgreSQL no “caminho” do que é alta prioridade — ETL, PostgreSQL, web. Tendo a ir pelo mais simples (driver). Faz sentido?

[avelino]

Faz sentido?

Faz sim, eu só "terceirizaria" o desenvolvimento da parte web (API) para alguém que consiga resolver isso com base no seu "database scheme" como o prestd, assim você coloca esforços em criar uma estrutura de dados que suporte expor via API (pensando no consumo de dados e o prestd faz seu show de expor a parte web).

Outro ponto é o "serviço" de ler o dado bruto (vindo da receita) e populando as tabelas no postgres.

[cuducos]

Perfeito, vai ser pREST assim que resolver a (eterna) #37