Yes, I firmly believe that microfrontend is a game-changer in Web development. Microfrontend enables the independence of development and deployment of Web apps while maintaining a fast, cohesive user experience.
Problem with today’s architecture
A large web app/site is typically divided into several sub-apps based on the URL path. For example, site.com/home and site.com/marketing are two separate apps. Each app maintains its own tech stack, from server to frontend.
Accordingly, Teams are organized to manage the two apps separately.
The reason for this architecture is to reduce dependency. By dividing the large site into two sub-apps, teams can manage their own development and deployment. Less dependency means more autonomy and faster movement.
However, this approach has downsides. The biggest problem is performance. When navigating from one page to the other, even though they seem two tabs next to each other on a page, it takes a full-page reload. The first app is unloaded and removed and the second app is downloaded, resulting in extra costs, including making another SSL handshake, requesting redundant server requests (e.g. user auth), and downloading the same code (e.g. react). And if the user switches back to the previous tab, it takes another wait to download the first app. This is a bad experience compared to single page application, which does client-side routing without full page reload.
Another problem is component reuse. Imagine there is a common UI widget between the home app and the marketing app. Reusing a component avoids duplicated engineering efforts and keeps UI consistent. To reuse a component, a typical approach is to publish the component as an npm package and npm install the component in each app. This, however, creates a dependency: it requires a redeployment of both the checkout app and marketing app at approximately the same time to avoid inconsistent user experience.
And who should be responsible for developing and maintaining a shared component? Since teams are organized on an app level, the ownership of a component is not immediately clear.
How microfrontend can help
In a microfrontend structure, site.com is a single-page application. site.com/home and site.com/marketing are two modules within the SPA. Each module maintains its independence of development and deployment.
Essentially, microfrontend allows the parent app to have access to module code in run time, as opposed to in build time. Conceptually, it’s like
Since the component code is imported in run time, a new version of the component is reflected immediately without the need for app redeployment.
In the world of microfrontend, everything except for the parent app is a component. Components can be pages, pure UI components, and API-connected components. The parent app is a skeleton that manages the mapping between routes and components. Navigating pages is simply mounting and unmounting module components.
With microfrontend, teams are naturally organized by components. A team manages a set of feature-defined components. The success of a team is evaluated not only by their app (page component) performance but also how they contribute to the broader success with their shared components. This finer-grained division better defines team boundaries, encourages cross-team collaboration, tracks team responsibility, and assesses the team’s success.
Cost
Microfrontend comes at a cost of more complicated architecture. It takes extra design in the coordination (e.g. passing state data) between a parent app and a sub-app and between two sub-apps.
Emerging technology such as module federation makes microfrontend easier to implement, but it is exclusive to Webpack5 and demands a learning curve.
Get Started
To get hands down to microfrontend, I highly recommend Stephen Grider’s lesson: Build incredibly scalable apps with a microfrontend architecture. And this is my GitHub code based on his lesson.
Summary
I am really excited about the change microfrontend is to bring to both the code architecture and the team organization. Dividing apps on a component level makes a lot more sense in many ways than on a page level. Microfrontend keeps the independence of app development and deployment in today’s architecture and brings a more coherent user experience by stitching components together in run time.
