Em primeiro lugar, eu genuinamente fico muito feliz em ter um lugar para ter dis · filipedeschamps

Em resposta a Discussão sobre trade-offs de implementação do TabNews

Em primeiro lugar, eu genuinamente fico muito feliz em ter um lugar para ter discussões técnicas e ter a garantia que será feita de uma forma saudável e sempre tentando extrair algum valor concreto. Então muito obrigado por criar esse post com essas perguntas Leonardo! 🤝

E tem um contexto que seria legal destacar e que vou demarcar no item zero e que pode dar uma antecipação de algumas respostas:

O TabNews não é um projeto no estilo "empresa privada" e é um projeto de "comunidade" e isso traz consigo algumas características e estratégias que eu pessoalmente não adotaria se fosse diferente. Então na medida do possível, ele precisa ser o mais simples e fácil para contribuição, mesmo que isso penalize a garantia técnica em alguns pontos.
Sobre TypeScript: é algo que já fui e voltei no assunto, mas acabei optando por JavaScript por ser mais simples. E não vejo o TabNews como um projeto "robusto", dado que a referência que tenho para isso foi minha experiência no Pagar.me. Lá era um ambiente de Fintech, crescimento maluco e usava JavaScript puro e teve alguns problemas por conta disso. Daí nesse caso eu não pensaria duas vezes em usar TypeScript. Só que não dá para negar que o fato de eu não ter maturidade em TypeScript influenciou na decisão de usar JavaScript. E projetando esse assunto para frente, eu esperaria vir tipagem nativamente no JavaScript que resolveria os bugs que sofremos no Pagar.me na época.
Não entendi muito bem o ponto de "mais poder de fogo". Isso no sentido de "desenvolvimento desacoplado" ou "escalonamento horizontal"?

Abração meu caro e vamos continuar essa conversa sensacional 👍

LeonardoSilva

3 anos atrás

Refletindo sobre o ponto 0 que você adicionou, realmente começo a entender melhor alguns aspectos do sistema. O uso de SQL "puro" ao invés de um ORM por exemplo (Era uma dúvida, mas imagino que o motivo de ser assim é exatemente este).

Entendo bem o seu posicionamento, eu particularmente usei JS muito pouco, adotei muito cedo o TS e uso ele em todos os projetos indiferente do tamanho. Me sinto perdido não tendo como checar as tipagens de objetos ou parâmetros e talvez por isso a decisão de usar JS tenha soado tão "estranha" para mim...
Me refiro a questões de não depender de um ambiente serverless para tudo, e ter um backend rodando em tempo integral. Vejo que o serverless é muito útil, mas imagino que ele traga algumas desvantagens relacionadas a abertura de conexão com banco de dados por exemplo. Inclusive um BD que é bem interessante em relação a isso é o Fauna DB que é muito usado em ambientes serverless por que a forma de interagir com ele parece muito uma requisição HTTP... Imagino que neste caso ele poderia ser até mais interessante que o Postgres, mas acho que você até já comentou em um vídeo dos membros sobre o desafio de usar o PG neste projeto hahaha

filipedeschamps

Autor

3 anos atrás

Sensacional Leo! Sobre o item 2, de fato vejo que uma das vantagens seria conseguir manter um Pool vivo 🤝

Mas novamente, é um tradeoff, pois acaba sendo um serviço adicional para gerenciar, ao ponto de não saber se o benefício compensa (ao menos hoje).

Digo isso, pois recebemos nosso primeiro DDoS e o gerenciador que criamos para o projeto se comportou muito bem:

Para chegar nesse estágio, precisou ser feito uma bateria muito legal de testes e entender o real comportamento das lambdas, principalmente no quesito de "guardar estado" entre uma chamada e outra (por conta do Pool). Registrei tudo isso aqui: https://github.com/brianc/node-postgres/issues/2718 (o resultado final está lá em baixo)

Seria até legal mais para frente criar um conteúdo aqui no TabNews detalhando como tudo foi feito 🤝