Where all backend services are broken down into smaller pieces the frontend services tend to stay as one single monolith. In this model multiple teams are responsible for building and operating all their own individual (micro)service. Another team, the frontend team is responsible for consuming those services, potentially as REST services and create a appealing user experience with it.
The problem with this is that there is a tight coupling, and with this a dependency, between the backend teams and the frontend team. The below image, drawn by Johannes Giani shows the common model as well as the alternative where the frontend is also broken into much smaller pieces.
Micro-UI and domain driven architecture
breaking the UI-monolith into UI fragments will allow for full decoupling between teams and will push the UI responsibility into the team responsible for the backend service. This makes that you can achieve a much higher level of domain driven architecture.
As an example, the team responsible for the shopping-cart, originally responsible for the backend services, can now also take the responsibility of the front-end services. There will no longer be a direct shared, or delegated responsibility, with the UI team.
Technical components
decomposing the UI-monolith into UI-fragments can be done in multiple ways, all having their pros and cons. The most promising one is the use of web components. Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.
Web Components allow you to basically include rich, custom build, features by creating your own "HTML tags". While having the freedom of custom build tags the entire "framework" of web components is a W3C standard and the entire web component idea is driven by Google who is pushing for the general adoption of web components in the browsers.
The architecture view
From an architectural view you have the more traditional and common deployment view on how microservices are used to decompose a monolith in the backend while still maintaining a monolith in the UI layer. This is shown in the below architecture diagram:
If we look at the use of web components you will have an architecture drawing as shown below.
Here you can observe a number of things;
- The UI elements are pushed down into the responsibility of the domain/service. This means that the team responsible for the backend services is now also responsible for the development and operation of the web component. This has become a complete and isolated service no longer depending on the UI team to provide the end-2-end service
- A new layer is introduced, the stitching layer (for the lack of a better word). The stitching layer is still developed and operated by a central UI team. The responsibility of this team is to ensure that all the (web) components are jointly integrated in a single UI.
On how the individual web components are being served and presented to the outside world is a discussion in itself and is primarily driven by the architecture views on routing and is not discussed in this specific post.
Conclusion
When decomposing a monolith, or building a greenfield microservice based application, it is a good thing to understand that the UI in itself can become a "new" monolith. Using technologies like web components can provide a solution to this and support a more clear domain driven architecture and provide less dependencies between teams while creating a higher level of end-2-end responsibility within an individual team
