The Android Backstage of Mercado Libre Warehouses
A small story about Mercury, WMS and Server-Driven UI
Read this story in Portuguese.
Intro
According to Roman mythology, Mercury was the god of trade and commerce. His figure is often related to speed for delivering other gods’ information or conducting business across long distances with his winged helmet and sandals. The Mercury Warehouse Management System (Mercury WMS) was born from this small story piece to fulfill Mercado Libre’s ambitious goal of building its own logistics operation in Latin America.
What’s Mercury WMS?
A Warehouse Management System (WMS) is a software application designed to support and optimize the operations of a warehouse or distribution center. The primary function of a WMS is to control the movement and storage of inventory within a warehouse, from its receiving to shipping. However, Warehouse Management Systems don’t work alone. Mercury forms part of a software ecosystem that integrates other applications such as Transport Management System (TMS), Order Management System (OMS), Yard Management System (YMS), and more. Even though these applications may have different client types, we will only discuss the Android WMS and how it escalates Mercado Libre’s logistics operation.
The natural offspring of features
When Mercado Libre started its shipping operation, the features required to be handled by Mercury were too few. The Android app was then developed using a common pattern of segregating features. Consider the following example:
The “Receiving” is an old feature of Mercury and internally, we also refer to these features as flows. In this case, nothing more than a loop of scanning events until reaches a successful end. Each screen presented here would have its own activity implementing a Movel-View-Presenter (MVP) pattern to deliver any logic required to operate that part of the shipping operation.
For starters, this worked well but didn’t last long. Many other flows were created with these same screens, most of them just replacing images or texts. The similarity of these flows and how they would replicate algorithms among MVP layers, generating a massive boilerplate as the business grew, started to bother in such a way that a new architecture had to be applied to allow the product to scale.
Server-Driven UI
In contexts where the business rules change too fast because the company learning curve is dynamically changing while its operation is being built, or especially for products that replicate the User Interface (UI) too much, an alternative to speed up development is to adopt a Server-Driven UI (SDUI) Architecture.
SDUI is an architectural pattern in software development that involves the server-side applications generating and delivering the UI and business logic to the client-side application, in this case, Mercury WMS. SDUI does not rely on the client-side to handle responsibilities. In this architecture, the server acts as the single source of truth, providing the app with the necessary data and UI elements when they need to be displayed for user interaction.
Another great advantage to be mentioned here is how SDUI helped with Mercury updates. Our WMS is an internal application. To access and download apps from the Play Store, a device requires synchronization with Google services, meaning there should be a Google account for each user on our operation. Obviously, we could not afford this. Since the shipping operation relies on shifts, Mercado Libre’s devices could not be bound to a single user such as in a personal device. By adopting SDUI on Mercury, we no longer had to deploy a new version of the app and wait for its adoption to change basic UI elements such as texts or images.
Flan
Flexible and agnostic as it can possibly be, Flan is how we’ve christened the Domain Specific Language (DSL) that we created using JSON data to specify how to implement features on our Android application without requiring any previous knowledge of development on this platform. Here’s how a scan screen was created for the Receiving flow using SDUI:
The many boilerplate activities used in different flows were replaced by a single one now known as ScanActivity. Thus we empowered Mercury’s UI, creating widgets and view presets to recycle them among different business flows.
There is no such thing as a silver bullet
Even though Mercury development became faster, since now we could build, change and completely wipe out flows from the server side, there is one major challenge that we face every day as a trade-off for using SDUI: granularity to apply UI changes on specific flows.
A typical example of this situation could be 10 flows sharing ScanActivity, where suddenly one of them requires a bold font weight title to be displayed on the toolbar. Until this requirement arose, there would be no way to change the toolbar title to apply this font weight for just one flow. The impact would reach any other feature on Mercury using this activity.
Without planning and developing our Flan framework as adaptable as possible, the Android client could rot, making some of the UI change requests unfeasible. This specific scenario was solved by wrapping the title with a font-weight tag. After deploying a new version of Mercury, any text on the app could be micro-manipulated to display bold messages.
Over the past years, Mercado Libre has learned a lot by building its private logistics operation. Mercury reflects just a tiny piece of how our shipping has grown healthy and is mature enough to attend to users’ demands. We continue to strive for our customers’ best experience by delivering every time farther and faster. Without creating the Flan DSL and adopting SDUI on our Android WMS, for sure none of this would be possible.
