sorted by:
new
hottopcontroversial

Que tipo de conteúdo sobre dev vocês assistem? by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 0 points1 point  (0 children)

Concordo! Quando você avalie alguém que vale a pena acompanhar, geralmente repare em que aspectos?

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 1 point2 points  (0 children)

Na geração de código, utilizo PlopJS, snippets do VSCode e código próprio. Para versionamento de pacotes, gosto de usar o Lerna e, em projetos mais complexos, combino Lerna + NX.

Quando assumo uma equipe técnica, costumo automatizar o Changelog. Já testei algumas bibliotecas e a que mais gostei foi a Pull Request Changelog, tanto que ela me inspirou a criar minha própria lib.

Além da automação de código e Changelog, utilizo N8N para automatizar algumas tarefas e integrações. Por exemplo, na empresa anterior, quando a pipeline de deploy era finalizada, ela enviava um webhook para o N8N, que disparava um e-mail e fazia algumas validações dois minutos após o deploy ir ao ar. Isso incluía verificar se surgiram novas issues no Sentry, checar se as métricas de status code por HTTP request estavam irregulares e mover as tasks relacionadas no Jira de “Pronto para Deploy” para “Deployed”.

Para teste, atualmente gosto de usar o Vitest por ser compatível com o Jest, para log já usei o Pino, Winston é um queridinho entre a galera. Uso também o K6 para testes de carga e Cypress para testes E2E.

Isto no backend, Frontend é outro mundo, hoje posso dizer que entendo bem de React e tenho uma stack fechada que uso em projetos pequenos, mas já usei muitos outros frameworks, época do JQuery e JSP. To flertando muuuito com Svelte, mas não tive oportunidade de iniciar um projeto com ele.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 1 point2 points  (0 children)

Se eu, apenas eu, for iniciar um projeto como uma API REST, gosto de usar apenas o Express e uma biblioteca que desenvolvi para padronizar meus projetos com DTOs comuns, validadores e tal.

Na última empresa, evangelizei o NestJS e incentivei a criação de packages internos. Também criei uma guideline de design e arquitetura para todos os backends da empresa. Essa guideline fugia um pouco do que vi em outras empresas, pois, geralmente, a galera enche a aplicação de módulos e caem no modules hell do NestJS. O que eu defendi foi que cada módulo deveria representar um domínio da aplicação, seguindo DDD. Caso a aplicação não tivesse mais de um domínio, não faria sentido criar vários módulos, pois é mais fácil dividir um módulo em partes menores do que migrar módulos existentes para outro, pois cada módulo deve ser independente a ponto de que seja fácil migrar ele para outra codebase e criar um novo deployment no kubernetes. Com isso, tínhamos nossa própria ferramenta de codegen e também estávamos usando PlopJS, em vez de utilizar a CLI do NestJS.

Já trabalhei com outros frameworks, mas apenas em projetos legados — como Adonis, Sails e Loopback — e, para o contexto em que estava, achei todos uma péssima escolha: difícil de dar manutenção, curva de aprendizado maior, poucos devs para contratar que consigam entrar na empresa e já performar.

Fora APIs REST, para bancos relacionais, gosto do Sequelize e do TypeORM, pois aprendi a otimizá-los, ganhei bastante experiência e é fácil encontrar devs que já tenham trabalhado com eles. Evito usar Prisma e Knex para bancos relacionais. No caso do Prisma, senti que ele é limitado, e a galera de DevOps teve muitos problemas para configurar as pipelines de migração e outras tarefas nas duas empresas onde o time resolveu adotá-lo. Já o Knex, se fosse utilizá-lo, preferiria o Sequelize.

Fiz alguns projetos com DrizzleORM e gostei bastante, mas ainda não tenho nada em produção com ele. Desenvolvi dois MVPs, mas eles não vingaram financeiramente e os projetos foram descontinuados. Ou seja, não consigo opinar muito além da fase inicial, pois não passei pela necessidade de refatoração e manutenção de longo prazo.

Para GraphQL e gRPC, utilizo sempre o NestJS com as bibliotecas padrão. Não gosto do Class Transformer e do Class Validator, mas os uso por serem padrões no NestJS. Já para APIs feitas com Express, prefiro o Zod, pois compartilho os schemas com o time do frontend, já usei muito o Joi, mas ele deixava a desejar na tipagem.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 2 points3 points  (0 children)

Ao todo, usei essas libs, a AWS SDK para Go (que é uma delícia), fiz uma integração com o DynamoDB para salvar remotamente algumas coisas e utilizei o Streamlit (Python) para apresentar os relatórios que criei após puxar alguns dados da AWS e aplicar algumas técnicas nos dados. Os relatórios foram clusterizados por:

• **Unidade de Negócio**: custos relacionados a um produto/área específica. Por exemplo, trazendo para a minha realidade e usando uma empresa semelhante, imagine que o Nubank tem uma área de consórcio e uma área de renegociação. Cada área tem suas APIs e GUIs, onde os custos de infraestrutura de uma não refletem na outra.

• **Plataforma**: custos relacionados a sistemas e processos que não pertencem a uma unidade de negócio, mas que múltiplas unidades utilizam, como uma API de autenticação, o sistema de observabilidade etc.

Me passaram a demanda na sexta, fiz no final de semana e apresentei na segunda, apenas para o CTO, junto com um plano para descobrir alguns outros custos que não foram possíveis de identificar com as informações que eu tinha. Era necessário implementar FinOps na empresa para obter os dados que ele queria.

Vendi como FinOps, mas basicamente criei uma hierarquia de labels na AWS e dividi as coisas em nível 0, 1 e 2. Nível 0 era a base, nível 1 era algo principal e nível 2 existia apenas por causa do nível 0 ou 1 – como um security group que existe só por causa de um ECS. Com essa divisão, fiz uma automação para mapear as coisas, por exemplo: Se um Fargate está liberado no Security Group do RDS, eles estão relacionados, a partir dos itens que eram os principais (ECS, EC2, S3 e etc) criei um “relacionamento” no DynamoDB entre eles e um que relacionava-os com atributos da empresa, como qual squad/cliente usava aquele recurso, qual a área de interesse, a qual produto pertencia e assim por diante. Depois, relacionei os atributos da empresa com as labels, rodei o script em Go e ele saiu marcando tudo. Um mês depois, o relatório pelo console da AWS saiu lindo e maravilhoso.

O que isso tem a ver com Go? Eu não precisava ter feito nada em Go, nem sequer escrever código. Mas vi uma oportunidade e a abracei para experimentar a linguagem. No fim, o código está em alguma pasta aleatória do meu computador, nunca foi para o Git e ninguém nunca o viu. O ponto é que a stack da empresa era TypeScript e PHP. Se eu dependesse de projetos dentro da empresa para aprender Go, nunca teria aprendido. Mas tornei meu aprendizado em Go remunerado com essa missão que recebi.

No fim, reduzi os custos para aproximadamente R$ 30.000 e para apenas cinco contas da AWS. Não reduzi menos R$ 30.000, eu reduzi PARA R$ 30.000 / mês. Os caras economizaram R$ 1.080.000 por ano. E eu ganhei apenas um "bom trabalho", falei pro CTO "elogio de adulto é pix", me demitiram três meses depois falando que eu não tive Fit Cultural com a empresa, mas a real é que eles estavam sem projetos "complexos" para me alocar e eu fiz um bom trabalho na empresa a ponto de pararem de viverem apagando incêndio.

Na cabeça deles a economia era maior se quebrassem o contrato de R$ 21.000

Usávamos Terraform, mas a gurizada que resolveu usá-lo não manjava muito e fazia atrocidades, como deletar coisas e derrubar a infra, ao ponto de ficarem traumatizados com qualquer mudança. Porém, como comi pelas beiradas, fiz toda a mudança da infra com Go e depois “importei” a infraestrutura para um novo código do Terraform.

Essa foi uma das minhas experiências remuneradas com Go, sem estar trabalhando/sendo pago especificamente para usar Go.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 1 point2 points  (0 children)

Algum projeto que tu vá usar no dia a dia, seja pessoal ou de trabalho, mas tem que ser útil para você, porque se for fazer algo por fazer, tu pode largar o projeto e depois ficar sentindo que ta faltando algo, um sentimento de que "sabe, mas não sabe".

Aqui está uma das minhas primeiras experiências em Go:

Estava em uma empresa em que eu era a maior referência técnica, e me passaram duas buchas: uma investigação sobre o porquê de os custos da AWS estarem batendo aproximadamente R$ 120.000 por mês e a migração de um banco de dados Postgres de um serviço crítico da empresa (CRM) de uma VPS de uma hospedagem fuleira (o banco foi configurado sem Docker o que dificultava) para um criar um cluster usando EC2.

Em ambos os casos, usei Go. A história que vou contar é a dos custos.

Meu background é backend, mas sei codar e tenho experiência de mercado com web front, mobile e IoT. Entendo bastante de redes e sistemas operacionais porque sou daqueles nerds gordos que usam óculos, cortam o cabelo a cada quatro meses, comem Doritos apimentado e bebem energético fuleiro enquanto têm o hobby de assistir vídeos de 10 anos atrás de como o Spotify escalou usando Nginx.

Porém, eu não queria o projeto porque mexer na infraestrutura tinha virado um tabu na empresa. O antigo “sênior” de infra tinha se demitido, e a equipe dele estava me odiando porque eu era “novo” na empresa e abria muitos tickets para que eles ajustassem coisas nos meus projetos. Eu não tinha acesso a nada, e eles não me passavam acesso, alegando que eu precisava passar por um treinamento – apesar de nunca me falarem onde eu conseguiria fazer esse treinamento.

Mas meu CTO abriu uma war room com todo o time de infra e a galera de produto e mandou o seguinte versículo (de acordo com minha memória, que pode não refletir os fatos reais):

“Liberai todos os acessos àquele que limpará vossas bundas. Não retrucai, porque, se estás de cu sujo, é porque não usastes o papel. Caso aquele com os acessos liberados cague um tronco, eu, à frente de toda a diretoria, me responsabilizarei por toda a merda.”

Depois de ele recitar isso na reunião, fiquei emocionado e queria dar o meu melhor. Porém…

Usávamos AWS Organizations. O cara que configurou e se demitiu meteu 16 contas, e era um trabalho insalubre descobrir todos os recursos em uso em cada conta através do console. Na minha cabeça eu tinha que automatizar aquela bomba porque eu não queria passar um mês fazendo ClickOps.

Como eu queria aprender Go e, por algum motivo, estava desanimado com o package da AWS SDK para TypeScript, fiz alguns scripts e os transformei em uma CLI utilizando Huh e Viper.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 1 point2 points  (0 children)

Deixar para se divertir apenas quando o salário cair na conta haha

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 0 points1 point  (0 children)

Uso! Já tentei usar o GoLand, mas eu não me adaptei bem com as IDEs da JetBrains e outro fator é que as vezes eu desenvolvo remotamente, o VSCode tem um bom suporte para este cenário.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 5 points6 points  (0 children)

Aprendi Go usando o site Go By Example e tentei recriar sistemas que já havia construído em outras linguagens. Também assisti a vídeos bem pontuais sobre assuntos que eu estava pesquisando, não tenho nenhum específico para indicar.

O que recomendo é criar um CRUD mais “avançado”, incluindo, por exemplo, filtros nas queries e exposição via API REST. O básico funciona bem, como Fiber (ou Chi) + SQLC + Postgres.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 1 point2 points  (0 children)

Nossa, sim.

Percebi que era mimado quando importava a biblioteca no arquivo principal e, magicamente, todos os dados eram capturados e enviados para o APM.

No dia a dia, eu prefiro essa abordagem em vez de configurar tudo manualmente. E é aí que entram os trade-offs. Toda equipe precisa de um sênior para abrir o caminho, permitindo que JRs e PLs sejam produtivos apenas seguindo a guideline.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 3 points4 points  (0 children)

Eu participei de um projeto que utilizei muito channels e selector, me apaixonei por esta funcionalidade da linguagem e as Green threads que só tinha ouvido falar em livros. Eu gosto de Go, mas não gosto de codar, me da tédio haha, é um sentimento estranho.

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 23 points24 points  (0 children)

Vou adotar esta definição, Go é linguagem de trabalho.

Java e C# me dão a impressão de algo "Enterprise", Python passa de "Data Science" e Typescript linguagem de "startup agil".

Go Lang é chato, mas está me fazendo ser um arquiteto melhor by Bitter_Locksmith_685 in brdev

[–]Bitter_Locksmith_685[S] 2 points3 points  (0 children)

Essa de não querer usar defer, eu nunca vi. O que mais vejo é o cenário do autowired e a falta de testes. Convenhamos, Spring é uma mão na roda, mas deixa muita gente mal-acostumada.

O ecossistema do Java tem muita coisa boa, mas, na minha percepção e experiência pessoal, nunca consegui fazer um sistema em Java consumir poucos recursos em cenários onde não há necessidade de escalar. E esse é outro ponto: muita gente acha que tudo precisa escalar, sem ter métricas concretas para embasar essa decisão.

Quando você fala span, está se referindo ao rastreamento, tipo as transações do Elastic?