Mini Web Apps: A Bounded Context for MicroFrontends with MicroServices

Developing web applications using Microservices is becoming a popular architectural style these days. When it comes to Microservices, we generally talk about the backend of the web application.

Only considering the backend for Microservices has a significant drawback, especially when it comes to web applications since the frontend is likely to become a monolith. Therefore, building a single frontend limits the benefits from Microservices, where it requires to deploy all the services and the frontend together.

Then, what are the possibilities for the frontend to adopt from Microservices paradigm? Can we break it down? The answer is simple, why not make it as a collection of Micro Frontends . However, designing Micro Frontends and Microservices together is easier said than done.

Introducing the Notion of Mini Web Apps

When designing a complex web application, it is useful to break it down into manageable smaller units representing domain-specific functionality. This way, a team could take full responsibility for the lifecycle (design, develop, and deploy) of a unit.

When considering the best approach to define the boundary of these smaller units, it is easier to model them as smaller web applications instead of Micro Frontends and Microservices.

I use the term Mini Web Apps to represent these smaller web applications that deliver specific business functionality.

However, you might wonder how these mini web apps work together so that a user could seamlessly navigate across these apps without even noticing?

Path-Based Routing

You could achieve the navigation between mini web apps using HTTP path-based routing. To support the navigation between each mini web app, each of them should own one or more HTTP paths, e.g.,/home, /shopping-cart.

For the end-users to see these mini web apps as a single application, it is essential to serve them via the same domain URL. Using Gateway Service or an Application Load Balancer, it is possible to set up a single domain for these mini web apps and route the requests based on the HTTP paths.

Each mini web app should be able to provide navigation to others by using HTTP paths of other mini web apps using HTTP URL links. It is also possible to pass any state-related parameters using URL parameters and sub-paths.

By following the best practices to optimize these mini web apps (e.g., browser caching), users won’t even be aware of switching between these mini-apps.

What about shared UI Components?

If there are shared frontend UI components like menu bars, it is essential to develop them outside the lifecycle of the mini web app. Shared UI components should be built as a separate project — then, encapsulate each component individually with all its dependencies and setup using Bit , and share it on Bit’s cloud . Shared components can then be imported to different mini web apps either as built packages, using NPM or Yarn, or imported with their source code, using Bit . Members of each mini web app team can then collaborate on each imported component (on their mini web app’s repository) and push it back to Bit’s cloud (as either a new version of the same component or as a new component).

An example of a collection of shared UI components on Bit’s cloud

Micro Frontend and Microservices for Mini Web Apps

When developing mini web apps, it is entirely possible to create them as a collection of Micro Frontends and Microservices. This way, you should be able to reap the benefits of both worlds. However, it is essential that a single team is entirely responsible and owns a mini web app, including both Micro Frontends and Microservices.

In most of the cases, it is likely to require to deploy both the Micro Frontend and Microservices together. However, the good news is, since one team handles both, they can take ownership of the changes and the deployments without depending on other teams.