Dividing Into Micro Front-Ends
Authors: Scott Phillips & James White
SailPoint is starting the journey towards decomposing its large single page applications into multiple Micro Front-ends. Micro Front-ends is a technology to break apart monolithic, single page applications into many smaller components that can be re-arranged into a modular, single page application. We will explore the reasons for this effort, the model being used for Micro Front-ends, some drawbacks, and future ideas we intend to explore.
Why Micro Front-ends?
SailPoint is migrating towards Micro Front-ends for several reasons. Primarily, as SailPoint’s engineering organization increases in size and scale, it becomes increasingly harder to manage dependencies, coordinating releases & roll backs between teams. Monolithic UIs owned by multiple scrum teams makes updating even simple dependencies a Gordian knot. Updating one dependency has immediate ramifications for other teams that may require additional updates within their area of the code base. Rollbacks to a piece of the code base may affect the release of a new feature elsewhere. Resolving these issues involves substantial communication between the teams to figure out an acceptable path forward. A much better solution to this dilemma is for each team owning, in its entirety, what they release while minimizing the dependencies upon other teams. Micro Front-ends enable teams to release & roll back their components independently of any other teams.
Secondly, Micro Front-ends allow us to support multiple modern web frameworks within a single-page-application. This is crucial, as SailPoint’s expanding portfolio of SaaS-based products are implemented in multiple web frameworks including Angular & React. Products will no longer have to stay within a single technology stack.
Lastly, this change will improve load time performance by limiting the amount of content that needs to be delivered to the browser. Only the initial set of resources needed to display that page should be loaded. As the user navigates to other areas of the application, additional parts can be loaded, decreasing the delay a user experiences when using the application.
SailPoint’s Micro Front-end Model
A Micro Front-end architecture has two main components: the App Shell, and a collection of Micro Front-ends themselves.
The App Shell is what is loaded first and is responsible for orchestrating the loading & unloading each of the Micro Front-ends themselves. Each Micro Front-end implements its specific part of the application.
In SailPoint’s model, there are two types of Micro Front-ends. First is a special purpose Micro Front-end to handle product wide navigation. This Micro Front-end is almost always present, and displays the common elements of the page, most notably the navbar at the top or side of the page. The other type of Micro Front-end in the SailPoint model are the Feature Micro Front-ends. Each Feature Micro Front-end implements a specific feature of the product such as a dashboard, access requests, certification, etc. In this model one Feature Micro Front-end is active at a time and has control over the full user experience, except for the navbar at the top or side.
Managing State
Another important aspect of this model is how to manage state. Under the SailPoint Model, the App Shell is responsible for maintaining a very limited application state. Application state refers to the data an application stores about what the user is doing. The limited state maintained by the app shell is:
- The user who is currently logged in and their oAuth token.
- The customer’s tenant the user belongs to (including any feature flags).
- Information about the request (such as what language should be displayed).
Beyond the state maintained by the App Shell, all other state is maintained internally by each Micro Front-end. Each Micro Front-end is free to choose the state management pattern that is best suited for the task. This may be a Redux pattern or nothing at all.
Micro Front-end Communication
Finally, the SailPoint Micro Front-end model limits communication. In this model there is no direct communication between any Micro Front-end. Each Micro Front-end is limited to direct communication with only two things: the App Shell, and the Browser’s environment. The App Shell provides an AppShellService that is injected into each Micro Front-end when it is loaded that provides an asynchronous typescript interface to the state managed by the App Shell. Micro Front-ends are expected to interact with the standard browser environment such as monitoring window.location for URL changes, using local or session storage.
Drawbacks
The big drawback to any Micro Front-end architecture is Web Components. Web Components use a browser feature to package interactive JavaScript components such as a DOM element. This allows these components to be easily re-used by just including that custom component in the DOM. This technology works by registering a JavaScript class with the browser for a particular name. Anywhere the browser encounters that name used as a DOM element, it will interact with that class to manage its contents.
The issue that causes problems with Web Components and Micro Front-ends in general is that once a JavaScript class registers a particular name within a Micro Front-end, there is no way to un-register it. Imagine the use case where two Micro Front-ends both pull in a Web Component as a dependency but one Micro Front-end is using version 1 of the Web Component while the other Micro Front-end is using version 2. The first Micro Front-end to load will register the version used by that particular Micro Front-end, then when the second Micro Front-end is loaded it will be forced to use the version that was loaded by the first Micro Front-end.
SailPoint is not planning on relying heavily on Web Components, except in certain cases. For these instances, we will skirt the version issue by naming the web components to correlate to a specific Micro Front-end. Perhaps in the future Browser standards will allow for un-registering, or re-registering Web Components to solve this issue.
The Future
SailPoint is interested in refining the Micro Front-end model as the transition to a Micro Front-end architecture is completed. One avenue we intend to investigate is expanding the model to support dialogs and overlays. The idea is that the App Shell could support displaying a modal dialog or overlay. With this a Micro Front-end could ask the App Shell to display another Micro Front-end within a dialog or overlay, pass as input some data into the dialog or overlay, and then receive a Promise for data returned after the dialog or overlay is closed or completed. This would allow some managed interaction between Micro Front-ends that may prove to be very useful while still maintaining the independence of Micro Front-ends to achieve our goals for Micro Front-ends.
Conclusion
We believe that implementing a Micro Front-end architecture will reduce dependencies between internal teams by being more Self-Service and adding more flexibility to address any potential deployment problems. Additionally, our external customers should enjoy reduced load times and increased responsiveness when using our applications. We’re extremely excited to begin testing this internally through the end of the year, and look forward to delivering further refinements in 2023.
