Um mergulho profundo no aplicativo Mailgun: parte 2 – uma execução triunfal

Quando iniciamos a jornada de reconstrução do aplicativo Mailgun, três longos anos atrás, passamos boa parte do tempo na prova de conceito, no planejamento e nos testes. Nosso objetivo principal? Criar uma experiência no aplicativo que destaque os diferentes produtos do nosso portfólio, permita uma navegação fácil entre eles e ofereça suporte a esses produtos de forma eficiente com uma única infraestrutura.

O escopo deste projeto foi tão grande que precisamos de mais de uma publicação para descrever o que motivou a reconstrução, como a fizemos, o que aprendemos e o que a implementação dessa nova tecnologia significa para o nosso futuro. Na primeira parte desta jornada épica, “Parte 1: ideias excelentes“, levamos você de volta no tempo para observar o nosso processo. Deixamos você entrar em nossas mentes e compartilhamos os motivos desse empreendimento, além de mostrarmos os desafios que sabíamos que enfrentaríamos.

Agora, na “Parte 2: uma execução triunfal”, vamos levar você aos bastidores para mostrar como implementamos esse projeto, como nossas equipes colaboraram e a função que o design desempenhou em nosso processo de pensamento.  Tem drama, tem migrações… e provavelmente algumas referências de ficção científica até demais. Junte-se a nós nesta jornada.

A motivação para atualizar o aplicativo Mailgun foi inspirada nas limitações da nossa infraestrutura legada, especificamente na nossa organização multirrepositório, em que cada projeto de front-end tinha seu próprio repositório, apesar de muitos projetos repetirem as mesmas tarefas. O que isso significou para as nossas equipes? Para começar, localizar um código específico ou encontrar bugs era quase tão fácil quanto Deckard caçando replicantes desonestos em uma cidade distópica densamente povoada.

Gerenciar vários repositórios com recursos redundantes reduz os tempos de resposta e esgota os recursos. Nossa solução? A reorganização em uma estrutura de monorepo modular. Nos termos de Blade Runner, em vez de caçar replicantes por uma cidade extensa, estaríamos navegando dentro de uma única megaestrutura em que os projetos são organizados em módulos e os replicantes se tornam pesquisáveis.

Esse plano de ação exigiria a implementação de novas ferramentas na nossa pilha, um novo visual para a nossa IU e o gerenciamento de grandes quantidades de código legado. Se você nos permite parafrasear: “O homem encontrou o seu par”… e agora o problema é da engenharia.

Uma das primeiras etapas na configuração do nosso novo aplicativo foi descobrir uma maneira de reutilizar o máximo possível do nosso sistema legado para não precisarmos reconstruir tudo. No entanto, não queríamos continuar a dar suporte a todas as nossas dependências legadas obsoletas. Precisávamos de uma forma de empacotar o nosso código existente para que ele não fosse rejeitado pela nova infraestrutura.

Module Federation é uma forma de definir um bloco de código (todo o nosso aplicativo legado, neste caso) como um recurso singular e importável, que pode ser autônomo ou configurado para compartilhar recursos com o consumidor. O Module Federation ofereceu uma solução que nos permitiu reempacotar o código existente para que pudesse ser consumido pela nova plataforma sem comprometer todos os novos recursos incríveis do nosso plano. A maior parte da nossa equipe de desenvolvimento poderia continuar fazendo correções de bugs e atualizações na nossa base de código antiga, e o novo aplicativo receberia tudo de graça!

Para fazer isso acontecer, precisávamos criar um middleware de roteamento declarativo que nos permitisse direcionar o tráfego entre os aplicativos antigo e novo. Portaremos o código legado gradualmente para a nova plataforma, mas, até lá, essa solução de roteamento por página nos permitiria lançar novos recursos sem perder o ritmo – e sem a dor de cabeça de reescrever tudo de uma vez. Como já definimos as regras, isso facilitaria a alteração e a manutenção do roteamento no nosso aplicativo.

Além dos componentes de migração em grande escala, também tivemos de resolver a migração e a adaptação dos processos existentes, focados em recursos que ainda precisariam funcionar de uma maneira familiar para o usuário no novo aplicativo.

Até agora, destacamos alguns dos elementos gerais, como armazenamento e gerenciamento de recursos. Porém, esse projeto foi uma reconstrução de todo o aplicativo Mailgun, que já continha processos em funcionamento voltados para a clientela que precisávamos proteger ou melhorar.

O processo de cadastro no aplicativo é um bom exemplo de como tivemos que avaliar os modelos atuais, trabalhar com várias equipes e implementar a nossa nova pilha. Ao dividir um projeto para a ação, há algumas perguntas que sempre fazemos:

1. Como obtemos e preparamos o plano para os dados atualmente?

Estratégia: documentar o cadastro atual e a lógica de criação de conta do processo existente do Mailgun. Isso nos ajudaria a arquivar nossos processos passados, mas também a analisar exatamente como íamos alterar o sistema atual para estabelecer as bases da nossa atualização.

2. Quais são as etapas da nossa iteração atual até o estado desejado?

Estratégia: depois de documentarmos e incluirmos nossas ações no plano, precisamos melhorar nossa base de conhecimento. Focamos no aprendizado das convenções e dos recursos do framework React que usaríamos para permitir a renderização no lado do servidor e recursos adicionais para dar suporte à nossa eficiência.

3. Que tipo de trabalho é necessário das outras equipes?

Estratégia: criar a IU. Como estávamos efetivamente mesclando dois produtos independentes em um pacote de produtos que compartilham uma infraestrutura, precisávamos criar a IU ao mesmo tempo que fazíamos as alterações nos produtos. Isso significaria que a maior parte das atualizações também seria um redesenho.

O nosso principal objetivo era diferenciar os nossos produtos – Mailgun e Mailgun Optimize – sem criar duas infraestruturas separadas para dar suporte a eles. Você poderia se perguntar: por que separá-los? Por que não apenas mesclar os produtos? Não seria mais fácil? Bem, na verdade não. Nossos produtos têm propósitos muito específicos, e a compra de um deles não significa que um usuário precise comprar todos eles. Além disso, o objetivo final por trás da reconstrução era desenvolver uma infraestrutura que pudesse dar suporte à adição de mais produtos no futuro, sem comprometer a funcionalidade do back-end nem criar uma situação em que os produtos fossem difíceis de navegar na perspectiva do usuário.

A solução? Design. Isso significou estabelecer novos padrões para os nossos aplicativos Mailgun e Mailgun Optimize em termos de ilustrações, cores da marca e formatação de texto. Isso também significou alinhar o marketing com a forma como falamos sobre os nossos produtos e como eles funcionam juntos.

Quando começamos a criar o processo de design, tivemos que considerar as áreas compartilhadas do aplicativo em comparação com as áreas específicas dele. Recursos como faturamento e o processo de cadastro seriam áreas compartilhadas, em comparação com as áreas independentes da IU, que atenderiam aos nossos produtos individuais.

Começamos em 2021 analisando a seção de faturamento e nos concentrando na lógica de como lidaríamos com a possibilidade de os usuários terem uma conta de faturamento compatível com o gerenciamento e a personalização de vários produtos. Isso definiu o tom de como iríamos avançar e analisar recursos como faturamento ou o nosso processo de cadastro, da perspectiva da convergência de vários produtos.

Mapeamos todos os pontos de contato que dependeriam de um espaço compartilhado ou de um espaço específico dos produtos dentro do aplicativo. Isso incluiu elementos como uma navegação à esquerda que seria específica do produto e incluiria configurações que também eram específicas do produto, mas que também garantiria que os espaços compartilhados no aplicativo seguissem os mesmos padrões.

Fizemos muita pesquisa da concorrência, e também de tendências gerais de padrões de design, para ver como a alternância entre produtos em um único aplicativo era feita atualmente e o que fazia sentido em relação ao que era necessário na navegação superior.

Nicki Snyder

Em seguida, analisamos os elementos da jornada do usuário, para que pudéssemos mapear a estrutura de design e os esquemas de cores que ajudariam a otimizar a experiência do usuário. Foram duas as perguntas que usamos para nos guiar:

1. Em qual fluxo um usuário entraria, agora que está navegando em um único aplicativo em vez de em dois aplicativos separados?
2. Qual seria o nosso plano para lidar e ajustar o fluxo de design em torno de um recurso específico no novo aplicativo?

Criamos designs que variavam as cores e o posicionamento para direcionar os usuários para as interações dentro do aplicativo e, em seguida, realizamos testes de usuário para observar e validar os caminhos do usuário. Para onde os usuários estavam navegando? O que os movimentos do mouse nos diziam sobre qualquer hesitação? O que as pessoas esperavam ver?

Com essas pesquisas de testes de usuário, conseguimos ajustar os elementos de design para otimizar a navegação de uma forma que fosse intuitiva para os nossos usuários. Depois disso, lançamos uma experiência Beta para usuários selecionados, que nos permitiu coletar informações de sessões e instâncias reais de usuários para nos guiar sobre o que funcionou e o que ainda precisávamos ajustar.

A mudança dos ativos visuais foi uma parte para a navegação e a outra para a unificação. Estilizar os menus de navegação com a nossa paleta de cores com identidade de marca pode parecer uma necessidade puramente estética, mas sabíamos que estávamos criando o tema de como nossos produtos se distinguiriam em um espaço compartilhado no futuro.

Criamos uma estrutura de navegação que pudesse ser dimensionada não apenas no Mailgun e no Mailgun Optimize, mas também nos nossos outros produtos de e-mail no futuro.

Nicki Snyder Diretoria de design e experiência do produto

Os ícones dos produtos permitiriam o reconhecimento independente da marca sem criar a confusão de mostrar os logotipos completos. Isso também nos daria a oportunidade de criar um caminho para o reconhecimento da marca para outros produtos do nosso portfólio, com links para eles a partir de seus ícones. Ao adicionar uma área Explorar no aplicativo, onde os usuários alternam entre os produtos, poderíamos ajudar a fazer vendas cruzadas para os usuários e aumentar o reconhecimento sobre o nosso pacote completo de produtos.

E, por fim, como equipe, achamos que seria muito legal ter um visual totalmente novo para acompanhar a nova tecnologia, de modo a ampliar o impacto de tudo o que havíamos criado de novo.

Os aplicativos não podem ficar estagnados, e o portal evoluirá com o tempo. Esse foi o principal objetivo de construir algo com a lógica e a infraestrutura feitas para dimensionar. Então, quais são as coisas que esperamos mudar primeiro?

• O refinamento da arquitetura de implantação: em “Parte 1: ideias excelentes“, falamos sobre o volume da programação que escrevemos na última década – milhares de linhas – e, assim como levará tempo para portarmos gradualmente esse código, também levará tempo para desativar os nossos processos de implantação anteriores. Isso significou que tivemos que criar o portal para funcionar com dois processos de implantação, nossos processos legados e nossa nova compilação usando o Cockpit – o que foi o empreendimento mais fácil de todos… Isso foi um pesadelo: dois processos de implantação! Nossa ambição é enorme.
• O gerenciamento de várias bases de programação: enquanto trabalhamos para portar gradualmente o nosso código, continuaremos precisando gerenciar várias bases de código e portar o código de diferentes conjuntos de produtos antes de podermos unificar.

O portal passou tanto pelos testes de usuário quanto pela fase Beta, portanto, conseguimos detectar e corrigir todos os bugs – como ninguém da engenharia diria na vida.

O redesenho do aplicativo foi executado para atender aos nossos usuários e também facilitar a vida das nossas equipes internas que o gerenciam. Assim, implementamos o feedback das observações e comentários internos e externos. Partimos com a intenção de que nenhum processo piorasse, de que a atualização do aplicativo não priorizasse um processo sacrificando a qualidade do outro. E temos a confiança de que tudo está tão bom quanto – ou melhor do que – a nossa versão legada.

Como se encerra uma publicação quando o projeto está em andamento? O aplicativo Mailgun saiu recentemente da fase Beta, e estamos fazendo pequenas melhorias regularmente enquanto preparamos o plano para os lançamentos maiores, que serão compatíveis com essa reconstrução inicial. Bill e Ted diriam para serem excelentes uns com os outros e continuarem festejando. Em termos de engenharia, isso significa que seguimos em frente e iteramos.

Esse projeto representa um marco importante na separação visual dos nossos produtos Mailgun e Mailgun Optimize no nosso aplicativo. Ele também representa uma mudança na tecnologia e em como estamos abordando o nosso desenvolvimento de front-end. Além de ser apenas um design bonito, focamos no desempenho para manter os nossos lançamentos pequenos e ágeis. As mudanças introduzidas com essa reconstrução foram o resultado de um incrível esforço de equipe, que nos permitirá nos afastar do nosso monólito legado de front-end.

Não conseguiríamos ter feito isso sem a ajuda da nossa equipe incrivelmente talentosa, e não queríamos encerrar essa série sem estender os nossos agradecimentos especiais a ela.

• Equipe central da IU: Nando Peña, Matt Leong, Matthew Prestlien
• Equipe de crescimento: Keith Cruz, Ryan Little, Jorge Miramontes, Mazen Abdul
• Equipe do Mailgun Optimize: David Ortiz, Dannon Gilbert, Jeffrey Jurgajtis, Peter Trinder
• Equipe do Mailgun: Celeste Rance, Jonathan Kruse, Iqbal Singh, Levi Trejo, John Badali, Chris Farmer, Nicki Snyder (design)
• Patrocinador executivo: Josh Odom

Esse projeto começou como um movimento de base dentro do Mailgun e cresceu à medida que se espalhou pelas equipes. Hoje, o nosso aplicativo atualizado oferece suporte a experiências mais elevadas para os usuários e a uma experiência melhorada para o desenvolvimento. Mas não terminamos. Nunca terminamos.

Você quer entrar nos bastidores e acompanhar as nossas histórias enquanto implantamos mais coisas legais? Assine a nossa newsletter para ficar por dentro.

Autor: Nando Peña Nando Pena is a Software Developer IV at Sinch Mailgun. He is a front end developer focusing on our core UI technology and experiences. He writes to share stories and experiences about developer projects.