Os Bastidores Android Dos Armazéns Do Mercado Livre
Uma pequena história sobre Mercúrio, WMS e Server-Driven UI
Introdução
De acordo com a mitologia romana, Mercúrio era o deus do comércio e das finanças. Sua figura frequentemente está associada à rapidez, por entregar informações de outros deuses ou conduzir negócios por longas distâncias com seu capacete e sandálias aladas. O Sistema de Gerenciamento de Armazém Mercúrio (Mercury WMS) nasceu dessa pequena peça da história para cumprir o ambicioso objetivo do Mercado Livre de construir sua própria operação logística na América Latina.
O que é o Mercury WMS?
Um Sistema de Gerenciamento de Armazém (WMS) é um aplicativo de software projetado para apoiar e otimizar as operações de um armazém ou centro de distribuição. A função principal de um WMS é controlar o movimento e o armazenamento do estoque dentro de um armazém, desde o seu recebimento até o envio. No entanto, os Sistemas de Gerenciamento de Armazém não funcionam isoladamente. O Mercury faz parte de um ecossistema de software que integra outras aplicações, como o Sistema de Gerenciamento de Transporte (TMS), Sistema de Gerenciamento de Pedidos (OMS), Sistema de Gerenciamento de Pátio (YMS) e outros. Embora essas aplicações possam ter diferentes tipos de clientes, discutiremos apenas o WMS para Android e como ele impulsiona a operação logística do Mercado Livre.
A prole natural das funcionalidades
Quando o Mercado Livre iniciou sua operação de envio, as funcionalidades que o Mercury precisava lidar eram poucas. O aplicativo para Android foi então desenvolvido usando um padrão comum de segregação de funcionalidades. Considere o seguinte exemplo:
O “Recebimento” é uma funcionalidade antiga do Mercury e internamente, também nos referimos às funcionalidades como fluxos. Nesse caso, não passava de um loop de eventos de digitalização até atingir um final bem-sucedido. Cada tela apresentada aqui teria sua própria atividade implementando um padrão Model-View-Presenter (MVP) para fornecer qualquer lógica necessária para operar essa parte da operação de envio.
Inicialmente, isso funcionou bem, mas não durou muito. Muitos outros fluxos foram criados com essas mesmas telas, a maioria deles apenas substituindo imagens ou textos. A similaridade entre esses fluxos e como eles replicariam algoritmos entre as camadas MVP, gerando um grande volume de código duplicado à medida que o negócio crescia, começou a ser um incômodo de tal forma que uma nova arquitetura teve que ser aplicada para permitir que o produto escalasse.
Server-Driven UI
Em contextos nos quais as regras de negócios mudam rapidamente devido à curva de aprendizado da empresa estar em constante mudança enquanto sua operação está em construção, ou especialmente para produtos que replicam muito a Interface do Usuário (UI), uma alternativa para acelerar o desenvolvimento é adotar uma arquitetura Server-Driven UI (SDUI).
O SDUI é um padrão arquitetônico no desenvolvimento de software que envolve as aplicações do lado do servidor gerando e entregando a UI e a lógica de negócios para a aplicação do lado do cliente, neste caso, o Mercury WMS. O SDUI não confia no lado do cliente para lidar com responsabilidades. Nessa arquitetura, o servidor atua como a única fonte de verdade, fornecendo ao aplicativo os dados necessários e os elementos de UI quando precisam ser exibidos para a interação do usuário.
Outra grande vantagem a ser mencionada aqui é como o SDUI ajudou com as atualizações do Mercury. Nosso WMS é um aplicativo interno. Para acessar e baixar aplicativos da Play Store, um dispositivo requer sincronização com os serviços do Google, o que significa que deve haver uma conta do Google para cada usuário em nossa operação. Obviamente, isso não seria viável. Como a operação de envio depende de turnos, os dispositivos do Mercado Livre não poderiam estar vinculados a um único usuário, como em um dispositivo pessoal. Ao adotar o SDUI no Mercury, não precisávamos mais implantar uma nova versão do aplicativo e esperar pela adoção dela para alterar elementos básicos da UI, como textos ou imagens.
Flan
Flexível e agnóstico como pode ser, Flan é como batizamos a Linguagem Específica de Domínio (DSL) que criamos usando dados JSON para especificar como implementar funcionalidades em nosso aplicativo Android sem exigir qualquer conhecimento prévio de desenvolvimento nesta plataforma. Veja como a tela de digitalização foi criada para o fluxo de recebimento usando SDUI:
As muitas telas com duplicidade de código usadas em diferentes fluxos foram substituídas por uma única atividade agora conhecida como ScanActivity. Assim, fortalecemos a UI do Mercury, criando componentes e telas padronizadas para reutilizá-los em diferentes fluxos de negócios.
Não existe bala de prata
Embora o desenvolvimento do Mercury tenha se tornado mais rápido, uma vez que agora podíamos construir, alterar e eliminar completamente fluxos do lado do servidor, há um grande desafio que enfrentamos diariamente como compensação pelo uso do SDUI: a granularidade para aplicar mudanças de UI em fluxos específicos.
Um exemplo típico dessa situação poderia ser 10 fluxos compartilhando a ScanActivity, onde de repente um deles requer um título em negrito para ser exibido na barra de ferramentas. Até que esse requisito surgisse, não haveria maneira de alterar o título da barra de ferramentas para aplicar esse peso de fonte apenas a um fluxo. O impacto alcançaria qualquer outra funcionalidade do Mercury que usasse essa atividade.
Sem planejar e desenvolver nosso framework Flan o mais flexível possível, o cliente Android poderia deteriorar, tornando algumas das solicitações de mudança de UI inviáveis. Esse cenário específico foi resolvido envolvendo o título com uma tag de peso de fonte. Após implantar uma nova versão do Mercury, qualquer texto no aplicativo poderia ser micro-manipulado para exibir mensagens em negrito.
Nos últimos anos, o Mercado Livre aprendeu muito construindo sua operação logística privada. O Mercury reflete apenas uma pequena parte de como nosso envio cresceu de forma saudável e está maduro o suficiente para atender às demandas dos usuários. Seguimos nos esforçando pela melhor experiência de nossos clientes, entregando com rapidez cada vez mais longe. Sem criar a DSL Flan e adotar o SDUI em nosso WMS para Android, com certeza nada disso seria possível.
