Executando verificação de segurança...
1

A decisão de manter Go e migrar só o front pra leptos faz sentido dado o problema: refazer a implementação de DB da lib Rust do WhatsApp pra suportar centenas de sessões custaria mais do que vale. E já pensar em leptos CSR visando Tauri depois é uma jogada inteligente, a compilação pro desktop fica bem natural. Como você está gerenciando o ciclo de vida das sessões WhatsApp no Redis quando a sessão fica inativa por muito tempo?

Carregando publicação patrocinada...
3

Não gerencio, a não ser que desconecte do whatsapp ele fica lá enquanto o servidor estiver ativo, alem de subir junto com o boot. Apenas se o admin da sessão desconectar que ele realmente é tirado do redis e fica só com as credenciais em standby no postgres (criptografado claro) para o proximo start tentar reconexão sem qrcode. Esse é justamente o motivo de eu manter o backend go que já tá bem otimizado, o redis acaba mantendo todas as sessões em memoria, o que é +/- 50mb por sessão.

1

50mb por sessão no Redis é bem razoável considerando que você elimina a reconexão com QR code. A parte inteligente é manter as credenciais no Postgres como fallback: você perde a sessão em memória mas mantém a capacidade de reconexão automática. Esse padrão de Redis como cache mais banco relacional como fonte de verdade resolve bem o trade-off entre custo de memória e latência em sessões de longa duração.

1

Eu sinceramente motivado pelas postagens de um outro usuario aqui do tabnews tô pensando em testar uma unlogged table do postgres no lugar do redis pra ver se consigo reduzir o uso de memoria enquanto joga a porrada inteira no postgres (unlogged tem througput alto por não ter WAL) se a latência não for muito mais alta para o uso é uma boa troca mas claro que tem que testar pra ver se o tempo resposta ainda tá bom e não tem um atraso muito alto na entrega de webhooks (notify do postgres) a ideia é realmente passar toda a responsabilidade da stack pro postgres sem cache, sem filas só o elefante.