Executando verificação de segurança...
6
LeonardoSilva
1 min de leitura ·

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

Olá, meu nome é Leonardo Silva sou desenvolvedor Frontend, e trabalho com React atualmente.

A ideia de criar um projeto como este é muito inspiradora para mim, e acredito que para muitos outros devs também. Então gostaria de aproveitar este espaço para criar um debate sobre tecnologia, focando nas decisões que o Filipe Deschamps tomou juntamente com os colaboradores do projeto do TabNews.

Destacarei dois pontos que me chamam atenção, e deixo o espaço livre para debatermos...

  1. Em um projeto tão robusto como esse por que não utilizar Typescript? Visto que isso ajudaria no desenvolvimento e até mesmo nas colaborações feitas por outros devs, uma vez que teríamos tipagens para objetos e funções...

  2. Porque desenvolver todo o backend utilizando o recurso de serverless do NextJS? Uma opção seria desenvolver uma api em Node separada do frontend. Isolando mais os ambientes e possibilitando "mais poder de fogo" para o backend em si.



Obrigado

Carregando publicação patrocinada...
2
filipedeschamps

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:

  1. 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.

  2. 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.

  3. 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 👍

3
LeonardoSilva
Autor
Autor

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).

  1. 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...

  2. 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

1
filipedeschamps

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 🤝

1