Micro Mobile Frontends in Action: Navigation Registry
If you have ever worked in a large mobile application code base, you would have faced the same issues with many developer that when the Business logic changes, added more flows to the current ones. And the more developers added to the project in term of making faster deliverable product, the messier and longer it takes to have a stable version.
I’ve been practising many solutions to solve this common issue, with the ultimate purpose that boost up the speed of delivering by adding more people and we still be able to manage everything neat and tidy.
I’ve been moving the methodology to build a large app ( super-app) from monolith to Micro Frontends architecture, and so far it is going great and mostly solved the problem of many people working in the same codebase.
Overall Objectives
Since we separated the scope of working that a group of developers will be working on, the structure of the project become much more scalable and easy to develop, maintain and independently deliverable.
But when it come to integration, which mean we compose all the modularized pieces into one final application, one of the issue is navigation between them. How to make it seamless while a module doesn’t depend on another, so, doing something like below is not applicable
Dynamic Customer Journey
Eventhough we structure the project in to separated scope, single responsible. But when it came to a real Customer Journey, which allows User go from this module to another, like in the picture
User can open the app, come to Newfeeds, then open Profile, and Carts, back to Profile, etc.
Which means, we must do, somehow, with the modularized architect, it should not against User’s experience whilst they are using the app. Navigating between modules must be seamlessly.
To have a seamless experience whilst navigating from module to module, while each doesn’t know about another, we came out with a middle layer, which is a coordinator who can help a module to navigate to another’s screen, seamlessly
Navigation Registry
The design of Navigation Registry is a map of routes
- Application level: Map of module
- Module level: Map of screens
So in practise, if we want to go from a screen inside a module, we will ask ApplicationRegistry to open that screen, without-knowing which module that screen belongs to.
Concept
MAFModuleRegistry
A shared module, which defines the protocols for NavigationRegistry
- Application level: MAFNavigationRegistry
- Module level: MAFModuleRegistry
UserModule’s registry
Same with NewsFeedModule and another modules
ApplicationRegistry
Navigating from a Module
POV: You are working in Newfeeds module and you want to open User’s profile ( which is a part of UserModule ). This is how
Output:
It is that simple.
Special case
Becase every module is developed by an independent team, so, there will be senariors that the screen we want to open is not ready (yet). There are few ways to handle this senarios
- Ignore ( do-no-thing) if the screen is not ready
- Display an error message: “Route/screen not found”
- Show a default screen (404-Page-Not-Found)
I prefer the last option, which is showing the default screen page not found :). The experience will look like this
Output:
Conclusion
The article here I just show the basic concept of how we designed the Navigation Registry. Furthermore, I’ve been developing the MAFNavigationRegistry to support more type of navigating like present, half-screen present, alert, action-sheets, etc.
The source code in the demo is here. Please feel free to try it.
