Análisis a fondo de la aplicación de Mailgun: parte 2 – Una ejecución de lo más triunfal

Cuando emprendimos el viaje de reconstrucción de la aplicación de Mailgun hace tres largos años, dedicamos gran parte del tiempo a pruebas de concepto, planificación y pruebas. ¿Nuestro objetivo final? Crear una experiencia en la aplicación que muestre distintos productos de nuestro catálogo, permita navegar fácilmente entre ellos y dé soporte a estos productos de forma eficiente con una única infraestructura.

El alcance de este proyecto era tan grande que necesitábamos más de un artículo para describir qué impulsó la reconstrucción, cómo la llevamos a cabo, qué aprendimos y qué supone para nuestro futuro la implementación de esta nueva tecnología. En la primera parte de este épico viaje, “Parte 1: ideas excelentes”, te hicimos retroceder en el tiempo para que observaras nuestro proceso. Te dejamos entrar en nuestras cabezas y compartimos nuestros motivos para este proyecto, además de guiarte por los retos a los que sabíamos que nos enfrentaríamos.

Ahora, en “Parte 2: una ejecución de lo más triunfal”, te llevamos entre bastidores para mostrarte cómo implementamos este proyecto, cómo colaboraron nuestros equipos y el rol que desempeñó el diseño en nuestro proceso de reflexión.  Tiene drama, tiene migraciones… y probablemente demasiadas referencias a la ciencia ficción. Acompáñanos en el viaje.

La iniciativa de actualizar la aplicación de Mailgun se inspiró en las limitaciones de nuestra infraestructura heredada, en concreto con nuestra organización multirrepositorio, en la que cada proyecto de frontend tenía su propio repositorio independientemente del hecho de que muchos proyectos repitieran las mismas tareas. ¿Y esto qué suponía para nuestros equipos? Para empezar, que localizar código específico o encontrar errores era casi tan fácil como para Deckard cazar replicantes rebeldes en una ciudad distópica densamente poblada.

Gestionar múltiples repositorios con funciones redundantes ralentiza los tiempos de respuesta y consume recursos. ¿Nuestra solución? Reorganizarnos en una estructura de monorrepositorio modular. En términos de Blade Runner, en lugar de dar caza a replicantes por toda una ciudad en expansión, navegaríamos por una única megaestructura donde los proyectos se organizan en módulos y los replicantes se pueden buscar.

Este plan de acción requería implementar nuevas herramientas en nuestro stack, un nuevo aspecto para nuestra interfaz de usuario y gestionar grandes cantidades de código heredado. Si nos permites parafrasear: “El ser humano ha encontrado a su rival”… y ahora es problema del equipo de ingeniería.

Uno de los primeros pasos para configurar nuestra nueva aplicación fue encontrar la manera de reutilizar la mayor parte posible de nuestro sistema heredado para no tener que reconstruirlo todo. Pero no queríamos seguir ofreciendo asistencia a todas nuestras dependencias heredadas obsoletas. Necesitábamos una forma de empaquetar nuestro código existente de modo que la nueva infraestructura no lo rechazara.

Module Federation es una forma de definir un fragmento de código (toda nuestra aplicación heredada, en este caso) como un recurso singular e importable que puede ser independiente o estar configurado para compartir recursos con el consumidor. Module Federation nos aportó una solución, ya que nos permitió volver a empaquetar el código existente para que pudiera consumirlo la nueva plataforma sin renunciar a todas las novedades que teníamos en el plan. La mayor parte del equipo de desarrollo podría seguir corrigiendo errores y actualizando nuestra antigua base de código, ¡y la nueva aplicación los obtendría gratis!

Para que esto fuera posible, necesitábamos crear un middleware de enrutamiento declarativo que nos permitiera dirigir el tráfico entre las aplicaciones antiguas y las nuevas. Poco a poco iremos migrando el código heredado a la nueva plataforma, pero hasta entonces, esta solución de enrutamiento por página nos permitiría lanzar nuevas funciones sin perder el ritmo, y sin el quebradero de cabeza de reescribirlo todo a la vez. Al haber definido ya las reglas, sería más fácil cambiar y mantener el enrutamiento en nuestra aplicación.

Además de los componentes de la migración a gran escala, también teníamos que resolver la migración y la adaptación de los procesos existentes centrados en funciones que debían seguir operando de forma habitual para el usuario en la nueva aplicación.

Hasta ahora, hemos arrojado luz sobre algunos de los elementos generales, como el almacenamiento y la gestión de recursos. Pero este proyecto consistía en la reconstrucción de toda la aplicación de Mailgun, que ya contenía procesos operativos de cara a la clientela que debíamos proteger o mejorar.

El proceso de registro de la aplicación es un buen ejemplo de cómo tuvimos que evaluar los modelos actuales, trabajar con distintos equipos e implementar nuestro nuevo stack. A la hora de desglosar un proyecto para pasar a la acción, siempre nos hacemos algunas preguntas:

1. ¿Cuál es nuestro plan actual de obtención de datos?

Estrategia: documentar la lógica actual de registro y creación de cuenta para el proceso de Mailgun existente. Esto nos ayudaría a archivar nuestros procesos anteriores y también a analizar de forma precisa cómo íbamos a modificar el sistema actual para sentar las bases de nuestra actualización.

2. ¿Cuáles son los pasos que van desde nuestra versión actual hasta el estado deseado?

Estrategia: una vez que hubimos documentado y trazado nuestro plan de acción, necesitábamos mejorar nuestra base de conocimientos. Nos centramos en aprender las convenciones y capacidades del framework de React que utilizaríamos para habilitar la renderización del lado del servidor y las funciones adicionales con el fin de dar asistencia a nuestra eficiencia.

3. ¿Qué trabajo se necesita por parte de otros equipos?

Estrategia: desarrollo de la interfaz de usuario. Dado que en la práctica estábamos fusionando dos productos independientes en una suite de productos que compartían una infraestructura, tuvimos que desarrollar la interfaz de usuario al mismo tiempo que introducíamos cambios en los productos. Esto significaba que la mayoría de las actualizaciones también serían rediseños.

Nuestro objetivo principal era diferenciar nuestros productos, Mailgun y Mailgun Optimize, sin crear dos infraestructuras independientes para ofrecerles asistencia. Podrías preguntarte por qué separarlos. ¿Por qué no simplemente fusionar los productos?, ¿no sería más fácil? Bueno, no del todo. Nuestros productos tienen propósitos muy específicos y adquirir uno de ellos no significa que un usuario tenga que comprarlos todos. Además, el objetivo final tras la reconstrucción era desarrollar una infraestructura capaz de dar asistencia a la incorporación de más productos en el futuro sin comprometer la funcionalidad del backend o crear una situación en la que los productos fuesen difíciles de navegar desde la perspectiva del usuario.

¿La solución? Diseñar. Esto supuso establecer nuevos estándares para nuestras aplicaciones de Mailgun y Mailgun Optimize en lo referente a ilustraciones, colores de marca y formato de texto. También supuso alinear el marketing con la forma en que hablamos de nuestros productos y cómo operan de forma conjunta.

Al empezar a desarrollar el proceso de diseño, tuvimos que considerar las áreas compartidas de la aplicación frente a las áreas específicas. Funciones como la facturación y el proceso de registro serían áreas compartidas, a diferencia de las áreas independientes de la interfaz de usuario que darían servicio a nuestros productos individuales.

Empezamos allá por el 2021 revisando la sección de facturación y centrándonos en la lógica de cómo íbamos a conseguir que el usuario pudiera disponer de una cuenta de facturación que fuera compatible con la gestión y personalización de múltiples productos. Esto marcó la pauta de cómo íbamos a avanzar y analizar funciones como la facturación o nuestro proceso de registro desde la perspectiva de la convergencia de varios productos.

Recopilamos todos los puntos de contacto que dependerían de un espacio compartido o de un espacio específico de los productos dentro de la aplicación. Esto incluía elementos como una navegación izquierda que sería específica de cada producto e incluiría ajustes también específicos, pero que a su vez garantizaría que los espacios compartidos de la aplicación siguieran los mismos patrones.

Investigamos mucho a la competencia, pero también las tendencias generales de patrones de diseño para ver cómo se hace hoy en día el cambio entre productos dentro de una misma aplicación y qué tenía sentido de acuerdo a lo que se necesitaba en la navegación superior.

Nicki Snyder

A continuación, analizamos los elementos del recorrido del usuario para poder trazar la estructura de diseño y los esquemas de color que ayudarían a optimizar la experiencia del usuario. Para orientarnos utilizamos dos preguntas:

1. ¿En qué flujo entraría un usuario ahora que se mueve en una sola aplicación en lugar de en dos aplicaciones separadas?
2. ¿Qué plan teníamos para gestionar y ajustar el flujo de diseño en torno a una función concreta dentro de la nueva aplicación?

Creamos diseños que variaban los colores y la llegada a la bandeja de entrada para dirigir a nuestra base de usuarios hacia interacciones dentro de la aplicación, y luego realizamos pruebas para observar y validar las rutas de cada usuario. ¿Por dónde navegaban los usuarios? ¿Qué nos indicaban los movimientos de su ratón sobre sus dudas? ¿Qué esperaban ver?

A partir de esta investigación de pruebas de usuario, pudimos perfeccionar los elementos de diseño para optimizar la navegación de una forma que resultara intuitiva para nuestra base de usuarios. Después de esto, se lanzó una experiencia beta para usuarios seleccionados que nos permitió recopilar información de sesiones e instancias de usuarios reales que nos guiasen sobre lo que funcionaba y lo que aún necesitábamos retocar.

Cambiar los recursos visuales fue por una parte una cuestión de navegación y por otra de unificación. Dar estilo a los menús de navegación con nuestra paleta de colores de marca puede parecer una necesidad puramente estética, pero sabíamos que estábamos creando la temática para distinguir nuestros productos dentro de un espacio compartido en el futuro.

Creamos una estructura de navegación que pudiera ser escalable no solo para Mailgun y Mailgun Optimize, sino también para nuestros otros productos de email en el futuro.

Nicki Snyder Directora de diseño de experiencia, Producto

Los iconos de los productos permitirían un reconocimiento de marca independiente sin crear la confusión que supondría mostrar los logotipos completos. Esto también nos daría la oportunidad de trazar un camino para el reconocimiento de marca de otros productos de nuestro catálogo al enlazarlos desde sus iconos. Al añadir un área para Explorar dentro de la aplicación en la que los usuarios cambiaran de producto, podríamos ayudar a las ventas cruzadas a nuestra clientela y dar a conocer nuestra suite completa de productos.

Por último, como equipo, pensamos que estaría muy bien contar con un aspecto nuevo y moderno que acompañara a la nueva tecnología para amplificar el impacto de todo lo que habíamos construido.

Las aplicaciones no pueden estancarse y el portal evolucionará con el tiempo. Ese era el objetivo principal de construir algo con una lógica e infraestructura hechas para escalar. Así pues, ¿qué es lo que esperamos que cambie primero?

• Perfeccionamiento de la arquitectura de despliegue: en “Parte 1: ideas excelentes”, hablamos del volumen de código que hemos escrito durante la última década (miles de líneas), y al igual que llevará tiempo migrar gradualmente ese código, también llevará tiempo retirar nuestros procesos de despliegue anteriores. Esto significaba que teníamos que crear el portal para que funcionara con dos procesos de despliegue: nuestros procesos heredados y nuestra nueva compilación con Cockpit, lo que resultó ser la tarea más fácil de la historia… ¡Fue una pesadilla, dos procesos de despliegue! Si algo nos sobra, es ambición.
• Gestión de múltiples bases de código: mientras trabajamos para migrar de forma gradual nuestro código, tendremos que seguir gestionando múltiples bases de código y migrando el código de distintos conjuntos de productos antes de poder unificar.

El portal pasó tanto por pruebas de usuario como por la fase beta, así que pudimos detectar y corregir todos los errores (frase que jamás pronunciaría un profesional de la ingeniería).

El rediseño de la aplicación se ejecutó para dar servicio a nuestros usuarios y facilitar la vida de los equipos internos que gestionan la aplicación. Por ello, implementamos las sugerencias de observaciones y comentarios tanto internos como externos. Partimos con la intención de que ningún proceso saliera perdiendo, de que la actualización de la aplicación no diera prioridad a un proceso en detrimento de la calidad de otro. Y tenemos la seguridad de que todo está igual de bien (o mejor) que en nuestra versión heredada.

¿Cómo terminas un artículo cuando el proyecto sigue en marcha? La aplicación de Mailgun acaba de salir de la fase beta y realizamos mejoras menores con regularidad, al tiempo que tenemos un plan para grandes lanzamientos que serán compatibles con esta reconstrucción inicial. Bill y Ted dirían: “Sed excelentes los unos con los otros y que siga la fiesta”. En términos de ingeniería, eso significa que seguimos adelante y que iteramos.

Este proyecto marca un hito importante en la separación visual de nuestros productos Mailgun y Mailgun Optimize dentro de nuestra aplicación. También supone un cambio en la tecnología y en cómo enfocamos nuestro desarrollo de frontend. Más allá de ser un diseño bonito, nos centramos en el rendimiento para que nuestros lanzamientos sigan siendo pequeños y ágiles. Los cambios introducidos con esta reconstrucción fueron el resultado de un increíble esfuerzo de equipo que nos permitirá alejarnos de nuestro monolito heredado de frontend.

No lo habríamos logrado sin la ayuda de nuestro equipo, de un talento increíble, y no queríamos terminar esta serie sin expresarles nuestro más sincero agradecimiento.

• Equipo Central de Interfaz de Usuario: Nando Peña, Matt Leong, Matthew Prestlien
• Equipo de Crecimiento: Keith Cruz, Ryan Little, Jorge Miramontes, Mazen Abdul
• Equipo de Mailgun Optimize: David Ortiz, Dannon Gilbert, Jeffrey Jurgajtis, Peter Trinder
• Equipo de Mailgun: Celeste Rance, Jonathan Kruse, Iqbal Singh, Levi Trejo, John Badali, Chris Farmer, Nicki Snyder (diseño)
• Patrocinador ejecutivo: Josh Odom

Este proyecto comenzó como un movimiento de base en Mailgun y creció al extenderse rápidamente por los distintos equipos. Hoy en día, nuestra aplicación actualizada está dando asistencia a unas experiencias de usuario de primer nivel, así como a una experiencia de desarrollador mejorada. Pero no hemos terminado. Nunca terminamos.

¿Quieres pasarte entre bastidores y seguir nuestras historias a medida que lanzamos más cosas interesantes? Suscríbete a nuestra newsletter para estar al día.

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.