TL;DR
Micro-services, a step further
Breaking the plain old monolith leads to well-known micro-services ecosystem. It is now time to deal with abandoned front end. It deserves greater attention.
Tidy up space & content
Tailoring an application includes split, bulkhead, layout & navigation. And their underlying rules & patterns.
Map & Model
Materialize micro frontends with purpose & I/O, as well as mini-map identification. Time to dive in further. Time for C4.
Web development
We are used to speak about front end and back end to materialize the separation of concerns between presentation layer & application/infrastructure ones when architecting web application. It also makes sense as technical stack is heterogenous e.g., TypeScript and Python. Organization can thus be shaped as either front-end team and back-end team, or as a single team whose members are referenced as full-stack dev because they handle both aspects.
Micro-services
As scratched in the previous issue, micro-services were introduced to split plain old monolith blob into highly specialized & easily scalable services. We both reduce the scope, hence the micro and strengthen the intent, namely, to serve, hence service. This move had solely been operated backend side.
Front-end monolith
At this stage, we end up with scalable and resilient back-ends powered by micro-services but still served to end-user via a single front-end aka Single Page Application. For sure, we can be smart leveraging widget/control/fragment reusable libraries, but we end up with a single composition root & entry point. As expected, focusing all the sustainability effort on one side leads to issue on the other one. Our frontend looks like plain old monolith compared to its back end alter-ego. We tasted how comfortable we feel to address brand-new use cases by simply composing/evolving/splitting/recombining/… our micro-services. We dream of tailoring new application by applying same paradigms, merging/morphing existing application shards. Because less nimble one slows down the whole fleet, front-end bottleneck emerges…
Silos
Main idea behind Micro Fontends is to shape our SPA as a bunch of self-contained features. Each feature addresses a specific domain of business, and provides end-to-end plumbing (presentation, application & infrastructure). Kind of vertical slicing focused on a dedicated bounding context, aka Silos.
Pros
Instantaneous gain is flexibility, whether for technical stack choices and even upgrades, or delivery shipping pace, while reducing coupling and dependencies. All well-known advantages we gain from micro-services architecture. Feature silos fit pretty-well Domain Driven Design paradigm as well. But with great power comes great responsibility…
Challenges
Composition
As for micro-services, all split gains have a cost, namely the merge counterpart. It is advocated to cope with that at the very beginning.
UI/UX consistency
Some of you may have noticed some discrepancies on famous marketplace websites like Amazon. Application acts as aggregator for micro frontends such as search, details, or checkout, but sometimes it is not as seamless as expected 😉.
Compatibility
As each feature can pick the most suited stack, one should pay attention to cohabitation at the very end. Duplicates & increased sizes of the shipped delivery need to be considered as well.
Parent/child & siblings communication
Agnostic features must cooperate to serve UX e.g., to trigger navigation or react to selection.
Loading & fetching
Because application is unaware of layout & workflow of underlying Micro Frontends, one need to set up strategies like skeletons-screens to enforce reactive UI.
Promises
If you decide to embrace this paradigm to craft your new Software Suite, you may have to pay huge tribute to set up the whole stack, but upcoming features are ready to reap the benefits. Fasten your belt.