Overview
This is the second article for Micro FrontEnds Architecture-how To series, we will review the shared runtime approach . Unlike their separate-runtime counterparts, shared runtime applications enable different micro frontends to exist and function within the same process, sharing memory and resources. This fosters a more cohesive and integrated experience for users, albeit presenting a unique set of challenges that must be carefully navigated.
This article aims to shed light on the available tools and techniques for implementing micro frontends from a shared runtime perspective. We will dive deep into the world of shared runtime micro frontends, exploring various technologies like web components and framework-based components, along with techniques such as transclusion. Each of these tools and techniques offers unique advantages and potential challenges. By understanding these in-depth, you can make informed decisions when architecting your next project.
Get ready to embark on this exciting journey into shared runtime micro frontends, understanding its intricacies, and discovering how to harness its potential to create seamless, scalable, and maintainable applications.
Web Components
Consider this: we have an HTML page teeming with diverse micro frontend applications, each thriving as an individual web component. It’s like a potluck, with each micro frontend bringing its unique dish to the table. Yet, they all share the runtime environment—serving resources from the same kitchen, if you will.
Each web component is like a mini-application living peacefully on an HTML page, with the content that it presents hosted on any web server. This is akin to a house party where each guest brings their food, yet everything’s served on the same table. Despite the shared space, each guest (or web component) retains their distinct identity, thanks to the magic of web standards.
Wondering about the secret recipe behind these extraordinary web components? Here’s the scoop—it’s a blend of several web standards, each contributing a unique flavor. Our first ingredient is the ‘Custom Elements Standard‘, letting us create recognizable HTML elements with a custom touch. Take, for instance, our ‘product’ micro frontend, which can be represented as a unique custom element using this standard.
Our next ingredient, the ‘HTML Template Standard‘, helps us define what goes inside these custom elements, like the toppings on a pizza slice. When our browser spots a custom element, it uses the HTML template to dish out your micro frontend.
But what makes web components truly stand out is their encapsulation ability, a characteristic offered by the ‘Shadow DOM standard‘. This element gives each micro frontend its special corner within the web component, allowing them to function independently. It’s like each party guest having their personal bubble, unaffected by what others are doing. So, despite sharing the runtime, our web components feel like they’re at their private party, thanks to the Shadow DOM.
We also have the ‘HTML Import Standard‘ acting like an open invitation, allowing different web components to be imported into various applications. These components then smoothly blend into any part of our application, creating an integrated user experience.
While the concept of web components sounds as tempting as a chocolate fountain at a dessert table, browser support across some areas can be a bit of a party pooper. But don’t worry! With a host of polyfills and support libraries, your micro frontends will shine as web components across all browsers.
Web components also give the micro frontends the freedom to communicate, chat, and interact with each other, just like the guests at a party. And they can fit right into mobile applications, much like a crowd-pleaser song that gets everyone moving.
Web components also score points in terms of micro frontend architecture design principles. They can be developed as autonomous features that can be independently changed and deployed without a hiccup. Teams can own each one of their micro frontend applications end to end, much like planning and executing an individual party segment.
They also offer the freedom to experiment with various technologies within the micro frontends. You can have one web component shimmying to the Angular beats, while another grooves to React. The encapsulation ensures no stepping on each other’s toes!
Web components offer a seamless user experience, superior to iframes. Think of it as dancing freely in a spacious hall versus tripping over furniture in a cramped room.
But remember, overloading with different frameworks can lead to a chaotic, resource-heavy application. It’s like cranking up the volume on all your speakers simultaneously Thus, it’s crucial to keep a check on the frameworks in use and continuously test for performance to avoid the dreaded party crasher—poor user experience.
Despite these considerations, web components allow us to deliver valuable features to our users. Think of it as catering to your guest’s unique dietary preferences at your party. Each dish (micro frontend application) has its unique appeal, yet all of them contribute to a memorable party (unified application).
Lastly, while our micro frontends look like mere custom elements on the surface, there’s an orchestra of backend microservices powering them in the background. It’s like the team of caterers and event planners who ensure your party is a hit. Every JavaScript call associated with a specific web component can tap into these microservices, offering a tailored experience for each micro frontend application.
Framework Based Components
In this part of our discussion, we are going to explore how we can utilize framework-based components as a means of constructing our micro frontend architecture. This approach echoes similarities with the use of web components, as both entail encapsulating your micro frontend applications within a component nestled within your web application.
The major contributors behind JavaScript frameworks such as Angular, Vue, and React anticipated the necessity of a modular frontend. These frameworks, while the standards around native web components were in the process of being finalized, introduced the concept of component architecture, providing the capacity to isolate portions of your frontend application into independent components. This very ability has catalyzed the evolution and adoption of the micro frontends architecture.
Relying on framework-based implementation for component architecture has brought the long-term need for standard native web components into the limelight. Currently, these framework-based components enjoy substantial support from both the community and large-scale vendors. Owing to this strong backing, enterprise-level applications find it convenient to adopt a framework-based architecture employing a popular JavaScript framework. This decision provides inherent modularity, an essential characteristic to support micro frontend architecture. However, it’s crucial to establish robust strategies and workflows to ensure your use of framework-based components aligns with the design principles of micro frontend architecture.
While framework-based components present significant advantages, certain challenges are associated with leaning on a framework for your component architecture. The first issue lies in the commitment towards a specific framework that forms the foundation for your micro frontend architecture. This choice may tether you to a particular JavaScript framework, contrasting with the flexibility offered by native web components that use standard web technologies and are not confined to any specific JavaScript framework.
Additionally, over time, transitioning to new advancements could become increasingly difficult as your application becomes more rooted in the initial framework. History shows us that even sizable frameworks from reputable vendors can be replaced over time. This necessitates a migration strategy which might prove quite cumbersome, particularly when you’re heavily invested in the component architecture of a specific framework.
Framework-based components do provide a degree of autonomy but the extent of it is limited. Changes and deployments require significant integration back into the base application, which can inadvertently affect other components. Concerns also arise when the base framework itself undergoes version changes. This necessitates an update across all micro frontend applications, followed by integration back into the base application.
Even though framework-based components are well-documented, supported, and provide a smooth user experience, they lock you into a specific framework. The user experience is further enhanced due to the optimized nature of the component architecture built around these frameworks. However, the limitation is that you lose the ability to experiment with different frameworks for your micro frontend applications that compose your entire application.
In conclusion, when contemplating the use of frameworks, you must weigh the longevity of the framework-based component model and the lifespan your application requires. Despite some trade-offs, framework-based components still manage to extend your microservices architecture. Micro frontends encapsulated in components can surface the functionality of specific microservices in the background, providing an end-to-end solution. In the following section, we’ll delve into the concept of transclusion as another potential strategy for delivering micro frontend architecture.
Transclusion
In this concluding section of our article, we explore a category of techniques and technologies referred to as transclusion, which can significantly assist in developing a micro frontends architecture. The two primary forms of transclusion, when applied as a solution to micro frontends architecture, are server-side transclusion and client-side transclusion.
Server Side Transclusion
The principle behind transclusion is quite simple: your application is an amalgamation of several other applications, rendered as one unified application. Each screen can consist of multiple micro frontend applications, which are compiled at the server-side when employing server-side transclusion. An engine running server-side formulates the overall page which is then dispatched back to the browser. This engine forms the page by sourcing from various application servers and merging the contents of those applications into one comprehensive page that is pre-rendered and delivered to the browser.
An example of a web standard facilitating this process is Edge Side Includes (ESI). ESI suggests incorporating tags within your HTML pages that allow the integration of content from various servers. These servers could host different web applications, and the content of those web applications can be integrated into this central page using ESI include tags. An ESI processor or engine running on a central server collects all the include tags, retrieves the content, and replaces the tags with the content. The final page delivered back to the client is a fully rendered page, including all the multiple applications that contribute to that one overall page. Various frameworks try to implement the ESI standard and provide an engine that pre-renders the page and delivers it to your browser.
There are several advantages to using server-side transclusion in micro frontends architecture. It simplifies client-side processing, reducing the need for heavyweight frameworks on the client side and enhancing the overall user experience, as the complexity of bringing these multiple micro frontends together is handled server-side by the transclusion engine. However, potential disadvantages include slow page delivery to the browser if server-side performance is inadequate. Also, there is currently no native method of achieving this, necessitating the use of third-party software as a transclusion engine.
Client Side Transclusion
Client-side transclusion is another method where your base web application uses technologies like AJAX to fetch your micro frontend applications from different servers onto one page, creating an illusion of one application. There are JavaScript libraries that allow transclusion within your web pages. However, this approach comes with its own set of drawbacks. The complexity is transferred from the backend system to the frontend application, which now relies on third-party libraries to perform transclusion and construct the overall application. Another concern is the performance at the client-side application end. If the frontend micro apps take different times to load, it could impact the overall page rendering speed and result in inconsistencies.
In general
Transclusion complies with micro frontend architecture design principles. Since micro frontend applications run independently in the background on servers, they can be independently deployed and modified, thus maintaining their autonomous nature. They can also be owned by a single team end-to-end due to their independent encapsulation. However, the technology needs to align well with the transclusion technology, which could limit technology agnosticism. There could also be a lock-in to a specific framework providing transclusion, raising concerns about future support. If support ceases, migration to another transclusion engine might be necessary, which would also involve reassessing the compatibility of micro frontend applications with the new engine. User experience can also be a concern, particularly if pre-rendering at the server end or transcluding at the client side is delayed.
Regarding value-driven micro frontend applications, they can still be independently optimized by a team to bring value to the customer and be included within the overall application. The application can be an extension of the functionality that the microservices expose in the background. There is nothing within the transclusion solution that impedes the use of our microservices architecture.
The transclusion technique provides a way to handle complexity, manage workload distribution between the server and client, and facilitates the integration of separate micro frontends into a cohesive application. This approach ensures that each micro frontend can still operate and be developed independently while being seamlessly integrated into the larger application.
However, it is vital to note that while transclusion comes with several benefits, it also introduces its own set of challenges. For instance, there might be dependencies on specific transclusion engines or third-party libraries, leading to potential problems with long-term support and compatibility with different technologies.
Furthermore, in terms of the user experience, the method of transclusion – whether server-side or client-side – can significantly impact the performance. Server-side transclusion might delay the delivery of content to the browser if the server-side processing is slow or inefficient. On the other hand, client-side transclusion might lead to slow page loading times or inconsistencies in the rendering of different parts of the application, especially if various micro frontends take different times to load.
In conclusion, while transclusion offers an effective solution to some of the challenges of developing a micro frontends architecture, careful consideration must be given to the choice of transclusion method, the potential dependencies on specific technologies or libraries, and the implications for user experience and performance.
Summary
Along these two articles, we have explored various methodologies and technologies that facilitate the development of a micro frontend architecture. Initially, we delved into strategies under the separate runtime category, which provide complete isolation for micro frontend applications using techniques from micro apps to iframes. Subsequently, we examined methodologies under the shared runtime category. Despite the potential drawbacks of a shared runtime, we found that each method had its unique approach to counterbalance these disadvantages and encapsulate micro applications effectively. This section included a study of distinct component implementations, both native and framework-based, to bring micro frontends to life. We wrapped up the contents by discussing an alternative technique for creating an application composed of micro frontends, namely server-side and client-side transclusion, which consolidate micro frontend applications into a unified application.
Hopefully, from this article as a whole, it becomes apparent that although the benefits of a micro frontend architecture are clear, there exists a range of strategies and technologies to implement this architecture.
That´s all so far, happy building folks !