Acho que não conseguir chegar numa explicação correta no pitch, até fiz algum... · guscsales

Respondendo a "Você usaria algo assim? Por quê (ou por que não..." dentro da publicação

Acho que não conseguir chegar numa explicação correta no pitch, até fiz algumas atualizações no texto acima. Lembrando que isso aqui é a ideia de um MVP, então é uma v0.

Jamais daria acesso direto ao DB à uma biblioteca que não é battle tested.

O "dar acesso" ao DB é em partes. A ideia seria gerar um update no schema, por exemplo no drizzle ou prisma, vc controla a tabela como quiser, com os indíces que quiser. E outra, nenhuma lib começou "battle tested", por isso que gosto do open-source.

Só o fato de não controlar como as querys são feitas (e quais índices são (ou não) usados) já descarta completamente a possibilidade pra mim.

Num sistema de key/value qual tipo de query tão intensa assim você imagina? E porque isso não poderia ser adaptado na lib para que a pessoa tenha mais controle?

Levando em consideração um projeto pequeno. Porque usar a sua lib e não um redis?

Ele pode usar, através de um adapter, assim como o adapter de drizzle sugerido, e nem vai ter o trabalho de configurar uma classe para fazer a instancia do redis, bem como um a logica para trazer os dados em tempo real. Esse seria um ótimo motivo para uma pessoa usar, seja o projeto grande ou pequeno.

Pilati

11 dias atrás

Num sistema de key/value qual tipo de query tão intensa assim você imagina?

Não é a intensidade, é a quantidade. Quanto mais querys acontecerem em um mesmo contexto mais lenta a aplicação vai ficar, sem falar na sobrecarga do banco.

Imagina ler 10 flags em cada request, milhares de vezes por segundo, não há banco que aguente.

vc controla a tabela como quiser, com os indíces que quiser

Perfeito, aqui é um grande ponto.

Mas as conexões do banco de dados serão criadas pela biblioteca? como será feito o pooling de conexões?

guscsales

Autor

11 dias atrás

Não é a intensidade, é a quantidade. Quanto mais querys acontecerem em um mesmo contexto mais lenta a aplicação vai ficar, sem falar na sobrecarga do banco. Imagina ler 10 flags em cada request, milhares de vezes por segundo, não há banco que aguente.

Sim, eu entendo e concordo. Só que isso é um cenário onde você já está com MUITOS usuários rodando ao mesmo tempo, não acho que é o caso da maior parte das pessoas que estão tentando subir um app, mesmo o resend hoje tem 1 milhão de usuários, mas boa parte não deve ser ativo.

Só que ok, vou ser honesto, isso pode (e vai) acontecer com alguém, então pensando nisso, a ideia já numa v0.0.2 é ter o Redis adapter para o cache, onde vc pode conectar com um redis local, um upstash ou seja la o que a comunidade preferir.

Meu plano é facilitar a vida de quem está criando um app, reduzindo fricção com coisas que são básicas. Essa pessoa precisa de velocidade, e normalmente não terá tantos users no início, então fazer isso no PG já resolveria um problema de não precisar criar tanto código para fazer um key/value ou manusear feature flags.

Mas as conexões do banco de dados serão criadas pela biblioteca? como será feito o pooling de conexões?

Através do seu adapter, vamos supor que vc está usando drizzle, as conexões são feitas direto no seu banco de dados normal do app, vc controla isso como bem preferir. O KV Layer iria criar uma nova tabela via migration, muito parecido com o que o better auth faz. O controle é todo seu.