mfbmina.dev

No fim do ano passado, minha equipe começou o seu projeto mais importante até então e acabei assumindo a liderança na organização do projeto. Fui responsável por coordenar as reuniões, o processo de entrega, etc. Durante os primeiros meses, o projeto foi andando bem, tomamos algumas decisões difíceis, provamos alguns conceitos e iniciamos o rollout da primeira fase.

Contudo, eu sentia que estava atrasando o time em alguns aspectos e que estava sendo um gargalo no processo todo. Em um 1x1 com o head da área, contei a ele sobre essa frustração e a resposta que recebi foi essa:

A primeira vez que ouvi falar sobre RPC foi em uma aula de sistema distribuídos, ainda quando estava cursando a graduação em Ciência da Computação. Achei legal, mas na época lembro de não compreender exatamente o porque eu usaria RPC ao invés de usar o padrão REST, por exemplo. Passa o tempo, e vou trabalhar em uma empresa em que parte do sistema legado era utilizando SOAP. Lembro de pensar: “hmm, interessante! Parece com RPC, mas traféga XML”. Anos depois, ouço pela primeira vez falar sobre gRPC, mas nunca entendi complementamente o que era, o que comia e pra que servia.

Quando optei pela carreira em computação, aos 15 anos, foi uma decisão baseada em gostar bastante de matemática e física. Queria me ver longe de escrever textos, redações e etc. Com o passar do tempo, essa visão foi mudando e agora uma das coisas na qual mais valorizo em uma equipe/empresa madura é a existência de documentação técnica.

Documentações nos ajudam a ter conhecimento histórico de decisões na empresa, nos ajudam a revisitar pontos e a entender melhor os pontos fortes e fracos dessas decisões. Além disso, elas são extremamente valiosas para novos membros da equipe, pois contam uma história de como vocês chegaram lá. Quanto mais detalhada, mais rica a história é.

Nos dias de hoje, é bem comum que nossa aplicação dependa de outras, principalmente se estamos trabalhando em um ambiente de microsserviços. É bem comum que nossa aplicação comece a reportar erros, que ao se investigar, notamos que alguma API de uma equipe parceira ou fornecedor está fora do ar.

Uma boa prática para aumentar a resiliência da nossa aplicação, é cortar a comunicação com essas aplicações que estão em estado depreciados. Observando outras áreas, absorvermos da Engenharia Elétrica o conceito de Circuit Breaker. Nele é colocado um equipamento, ou disjuntor, que se desliga automaticamente caso alguma falha aconteça. Isso é muito comum em nossas casas, que possuem disjuntores que se desligam sozinhos caso a rede elétrica comece a ficar instável.

Escrever um jogo é uma ótima maneira de se começar a programar, principalmente pois diversas pessoas começaram a programar por que queriam criar jogos para computadores ou até mesmo video game. Inclusive, um dos meus primeiros “projetos” foi um joguinho, ainda quando cursava o curso técnico em Informática Industrial, em 2010.

No curso, utilizávamos Python e implementamos um slide puzzle. Foi bem desafiador na época, pois tive que entender da mecânica do jogo, de como criar uma GUI, mas entreguei o projeto. Quando comecei a trabalhar com Ruby, também fiz uma implementação para comparar com o que já tinha feito em Python.

Linter é uma ferramenta de análise estática de código que é usada para encontrar erros de programação, bugs, falta de padronização de código e até mesmo falhas de segurança. Essas ferramentas ajudam os desenvolvedores pois permitem que bastante tempo seja salvo, já que identificam problemas antes mesmo de chegarem em produção. Além disso, são extremamente utéis no processo de code review, já que salvam os desenvolvedores de desnecessáriamente avaliar se o colega utilizou os padrões da equipe ou não.

Computadores e linguagens de programação surgiram para facilitar as nossas vidas e automatizar as tarefas do cotidiano. No dia a dia de nós, programadores e engenheiros de software, muitas vezes temos que criar diversos arquivos semelhantes, cujo um ou outro campo muda de forma sutil. Um exemplo claro são arquivos de configuração, faturas, XMLs, HTMLs ou qualquer arquivo que nos permita gerar arquivos similares mudando poucos pontos. Existe uma solução simples para esse problema: criar um template e ir alterando só as partes que preciso de forma manual! Contudo, isso não é a melhor forma de resolver o problema, pois ela não é escalável. Além de que podemos utilizar tecnologia para facilitar nossas vidas.

O Kong, segundo a própia documentação , é um apigateway open source, criado para a nuvem, agnóstico em plataforma, feito para alta performance e extensível via plugins. O Kong possui uma grande gama de plugins oficiais que nos permitem fazer grande parte das customizações que necessitamos e quando o plugin não está disponível, podemos criar nosso própio plugin.

A linguagem padrão para se criar plugins é Lua, contudo outras linguagens são suportadas e uma delas é Go. Pessoalmente, não tenho experiência em escrever códigos em Lua, portanto, utilizar Go me permite uma maior velocidade de desenvolvimento e maior qualidade no plugin.

Uma das funcionalidades mais legais de Go é a facilidade de se utilizar concorrência. A linguagem nos fornece as chamadas goroutines que são lighweight threads gerenciadas pelo própio runtime do Go. Concorrência nos permite rodar diversas funções ao mesmo tempo. Isso é extremamente útil caso você queira melhorar a performance de sua aplicação.

Para utilizar essa funcionalidade, basta colocar a palavra-chave go antes de qualquer função e ela automaticamente vai estar rodando de forma concorrente. Para ficar mais fácil de entender, vamos ver um pouco de código. Aqui está implementado o SleepSort, é um algoritmo de ordenação que utiliza um sleep para poder colocar cada elemento no seu lugar.

Atualmente grande parte dos fluxos de autenticação se baseia em gerar um token, que pode por exemplo usar o padrão JWT, e o frontend faz as requisições informando ao backend quem é o usuário que está de fato realizando a chamada. Isso pode ser observado com as requests do frontend enviando o header Authorization nas requests.

É comum que esse token contenha informações do usuário, como por exemplo o id. Então ao receber a requisição, o backend decodifica esse token para extrair essas informações e assim relacionar com algum usuário do banco de dados. Com o usuário em mãos, executamos a ação desejada. Logo abaixou vou dar um exemplo de um serviço em Go que faz exatamente isso.