Na minha opinião, Go fornece um excelente suporte a se trabalhar concorrentemente não só pelas goroutines, mas pelo ecossistema da linguagem. Um grande exemplo disso é o pacote sync, que auxilia na sincronização das rotinas concorrentes. Neste post, vamos aprofundar em tudo que este pacote pode nos oferecer.

Waitgroups

Waitgroups são utilizados para coordenar a execução de diversas rotinas. Ele facilita a criação e a garantia de que todas as sub-rotinas serão finalizadas antes de finalizar a rotina principal. No post sobre waitgroups explico melhor como elas funcionam e o que mudou com a versão 1.25 do Go.

Imagine o seguinte problema: é necessário processar centenas de registros e gerar uma única saída. Uma forma de resolver é processar cada registro sequencialmente e só no fim unificar a saída. Contudo isso pode ser extremamente lento, dependendo do tempo gasto para processar cada registro. Outra forma é fazer o processamento de forma concorrente, acelerando o tempo gasto para o processamento. No meu post sobre introdução à concorrência falei um pouco sobre goroutines e channels e agora decidi falar sobre os waitgroups, uma forma de simplificar a gestão de múltiplas goroutines.

Em um post anterior mostrei algumas formas de melhorar os testes criando mocks das APIs que chamamos. Porém, isso nem sempre é suficiente e podemos precisar de testes E2E (ou testes de aceitação), como, por exemplo, para testar integrações com banco de dados, serviços de mensageria ou qualquer outra coisa. Para esses casos, venho apresentar a ferramenta Testcontainers.

O testcontainer é uma biblioteca open-source que permite que você crie containers durante a execução dos testes. A ideia é que as dependências de teste da sua aplicação sejam parte do código, evitando a necessidade de mocks e até mesmo a instalação local de dependências. Outra grande vantagem é que dessa forma é mais fácil conseguirmos isolamento entre os testes e replicabilidade entre os desenvolvedores. A ferramenta suporta diversas linguagens de programação como Go, Ruby, Elixir, Java, etc.

Conforme o software que trabalhamos vai crescendo, a tendência é do código passar por diversas mudanças e refatorações. Nesse processo, podemos simplesmente esquecer pedaços de código que um dia foram utilizados e que agora não fazem mais sentido no projeto, os famosos códigos mortos. Um exemplo muito comum é quando uma API é desativada e só o handler é removido, porém, toda a lógica de negócio continua ali, mas sem ser utilizada.

No post sobre Circuit Breaker, citei que atualmente é comum que a sua aplicação tenha que se comunicar com outras e, com isso, estratégias de controle de tráfego se tornam essenciais. Recentemente descobri o Token Bucket, uma estratégia baseada em tokens para controlar o tráfego.

Imagine que você tenha 5 ingressos para um brinquedo e que a cada hora você ganhe um novo ingresso, mas nunca podendo exceder o limite de 5. A cada ida ao brinquedo, um ticket é usado. Dessa forma, ao utilizar todos os seus tickets, você não pode ir ao brinquedo até ganhar um novo ticket. É um algoritmo bem interessante, utilizado, por exemplo, pelo PIX, para controlar a busca de chaves e evitando que um malfeitor pegue dados de usuários.