O que aprendemos ao abrir o código de grande parte do Mailgun

Há algumas semanas, abrimos o código do Flanker, nossa biblioteca de análise de MIME e validação de e-mail. Ficamos muito felizes com o lançamento e com o nível de interesse demonstrado pela comunidade Python. Este tweet é um exemplo típico do que temos ouvido desde o lançamento:

Transformar um software em código aberto pode parecer fácil, mas é mais complexo do que simplesmente colocar o seu software no GitHub e dar o trabalho por encerrado. Na verdade, nos surpreendemos com alguns dos desafios que enfrentamos e queríamos compartilhar nossas experiências sobre o processo na esperança de ajudar outras equipes de desenvolvimento com o plano de abrir seu próprio código. Para isso, veja como fizemos e o que aprendemos.

Originalmente, nos comprometemos a abrir o código do Guardpost, nosso validador de endereço de e-mail. Quando começamos esse processo, percebemos rapidamente que isso seria muito mais valioso se fosse empacotado com a nossa biblioteca de análise de MIME e lançado em conjunto como Flanker. Isso levou a complicações adicionais, pois agora estávamos abrindo o código de uma parte bastante grande da base de código principal do Mailgun.

Como o Flanker não foi projetado originalmente para ser usado por outras pessoas, foi um desafio garantir a remoção de todas as dependências da base de código proprietária. Não queríamos impor nosso uso de tecnologias específicas a outras pessoas, então pegamos as partes do Flanker que usavam módulos específicos do Python ou bancos de dados como Redis e dnspython e as tornamos mais modulares. Agora você pode usar qualquer banco de dados (ou nenhum) para armazenar seus resultados em cache.

Isso significava que tínhamos que primeiro extrair o código e nos certificar de que seria consumível por terceiros para, em seguida, integrar efetivamente o Flanker de volta ao Mailgun em sua nova forma. Também aproveitamos esta oportunidade para refatorar grandes partes do analisador de endereços (veja o item 5 abaixo), o que tornou as coisas mais difíceis.

Poderíamos simplesmente ter feito um fork da nossa base de código interna do Flanker, nos esforçado para remover as dependências e voltado a usar o que já estava funcionando internamente. No entanto, dessa forma, estaríamos negligenciando o código aberto ou mantendo duas bases de código diferentes. Em vez disso, decidimos nos comprometer a continuar usando o código aberto em produção.

Isso significa que, ao fazer o merge de um pull request (já fizemos oito desde que abrimos o código do Flanker há algumas semanas, e temos mais quatro pendentes), não só temos que garantir que o código seja limpo, de fácil manutenção e voltado ao desempenho, como também precisamos nos certificar de que todas as alterações funcionem bem com o restante do Mailgun.

Como você pode imaginar, a análise de endereços e a análise de MIME são essenciais no Mailgun. Como fizemos grandes modificações no processo de abertura do código, tivemos que tomar muito cuidado ao integrar o código aberto de volta ao Mailgun sem prejudicar os aplicativos da clientela. Talvez não seja tão impressionante, mas pareceu um pouco como fazer espacate entre dois caminhões andando de ré.

Conseguimos isso implementando o Flanker em fases. Primeiro, começamos liberando o Flanker para uma pequena parte do nosso tráfego. Isso nos permitiu começar a ver situações nas quais o comportamento do novo analisador de endereços era mais rigoroso do que antes. Para certas coisas, como permitir caracteres de controle em nomes de exibição, decidimos proibir isso, pois é um risco de segurança. Para outras coisas, como o suporte a Unicode, decidimos ser o mais flexíveis possível quanto ao que aceitaríamos. Sim, isso significa que agora você pode enviar o caractere de cocô como nome de exibição por meio do Mailgun, e nós o codificaremos corretamente e o repassaremos.

Também achamos que seria sensato ver se poderíamos abrir o código sem perder o emprego. O Flanker é uma das peças centrais do Mailgun, então é bastante valioso para a Rackspace. Embora acreditemos que, às vezes, é uma boa estratégia pedir perdão em vez de permissão para fazer as coisas acontecerem, esta provavelmente não era uma daquelas ocasiões. Então, consultamos as equipes jurídicas e de produtos da Rackspace para garantir que estavam de acordo. Felizmente, o slogan da Rackspace é a “empresa de nuvem aberta” e ela se dedica ao software de código aberto, então não foi difícil convencer o pessoal de que abrir o código do Flanker era a coisa certa a se fazer.

Operamos nosso analisador de MIME em produção há muito tempo, mas a parte do validador de e-mail (Guardpost) era relativamente nova. Lançamos o Guardpost como uma API antes de abrir o código do Flanker. Isso nos permitiu testar efetivamente em condições reais antes de abrir o código.

À medida que o Guardpost se tornou popular, mesmo rodando em uma máquina dedicada bastante poderosa, ele estava tendo problemas para lidar com o tráfego que recebia. Então passamos um tempo analisando o perfil do Guardpost procurando o que estava causando a lentidão, e descobrimos que era o corretor ortográfico. Passamos um tempo pesquisando como poderíamos melhorá-lo e acabamos reescrevendo tudo. Você pode ver nosso post no blog sobre como conseguimos deixar o corretor ortográfico 135 vezes mais rápido do que antes.

Também conseguimos consertar uma boa quantidade de bugs encontrados pelas pessoas. Isso incluiu desde adicionar o suporte do Internet Explorer para nossa demonstração de validador (ninguém na equipe tinha uma máquina com Windows, então tivemos que adquirir uma licença para corrigir esse bug!) até enviar e-mail diretamente a um domínio de nível superior (TLD).

Rodar o código em produção antes de abri-lo nos deu confiança e orgulho do que estávamos disponibilizando para o mundo.

Isso é muito importante. Quando você tem uma base de código interna na qual está trabalhando, pode ir até quem a desenvolveu e fazer uma pergunta rápida. Esse não é o caso do software de código aberto. Por isso, queríamos garantir que o Flanker fosse bem documentado para que ficasse mais fácil de usar para novas pessoas. Isso significa que o Flanker está bem documentado no próprio código com comentários, além da documentação externa como uma Guia de início rápido, Manual do usuário, e referência da API.

Então, foi isso que aprendemos ao abrir o código do Flanker. Embora tenha dado muito trabalho, foi um processo libertador e esperamos colher os frutos no futuro.

Adoraríamos saber sobre as suas experiências nos comentários deste post ou no HackerNews.

Os Mailgunners

Autor: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!