Você usaria algo assim? Por quê (ou por que não)? Pessoalmente não usaria. Ja... · Pilati

Em resposta a

Você usaria algo assim? Por quê (ou por que não)?

Pessoalmente não usaria.

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

A chance de dar ruim é muito grande!

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.

Em projetos pequenos e com pouca escala isso não importa. mas quando começa a ter escala e o custo por query começa a ser levado em conta isso pode virar um pesadelo.

Aliás o funcionamento é extremamente semelhante ao Redis (sim, eu sei o estrago que pode ser feito no projeto usando o DB como cache)

Meu fluxo atual de cache é guardar os dados brutos no DB e carregar pra cache sob demanda. Essa cache pode ser tanto distribuída (redis) como memória do processo para dados frequentes. Cada camada gera um trade-off de invalidação dessa cache

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

guscsales

11 dias atrás

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

Autor

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

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.