This is the second in a series of posts that will explore the concepts and practices for implementing Micro Frontends.
As I stated in my previous post, Micro Frontends allow you to divorce a micro-service from the UI of the applications that consume the service. By delivering the UI component as a part of the micro-service:
- The consuming application no longer needs to concern itself with the presentation of the data.
- The service becomes completely independent with its own deployment cycle, meaning that it can deliver enhancements and bug fixes as needed without impacting the cycles of any application that consumes its service.
It doesn’t matter if the consuming application is a “traditional” multi-page application, a SPA or a Progressive Web Application with a thin-client installed on the user’s machine.
The question becomes, how? What are the various techniques for integrating Micro Frontends? What are their strengths and weaknesses?
I would like to give a brief overview of some of the available techniques. This is not a comprehensive list. Technology is always evolving and there will be things I haven’t discovered.
Hyperlink:
Plain old hyperlinks are one of simplest methods, just add a link to the main page and you’re done, quick, easy, and they are loosely coupled. The only thing a calling application needs to know is the Micro Frontends’ endpoint. This means that the team providing the service can update, enhance, and fix bugs without ever impacting the application that calls their service.
The downside is that every click renders a new page. A complex page, or a slow connection, this can introduce a lot of latency. It also requires the user to use the Back button a lot.
Iframe:
I know what you are thinking. iframe! Really?! Iframes are often maligned because some browsers may not render them the way you expect. There is the potential for slow load times. If the page being rendered has been poorly written, it may have security vulnerabilities. Additionally, Search Engine Optimization is very poor for iframes.
They have all the same advantages as plain old links and they eliminate the need for the user to navigate via the Back button. In addition, they provide a high level of isolation for styles and scripts. The built-in security features of iframes generally shield other parts of the application from any security vulnerabilities that may exist within a given iframe. If you keep the content they are expected to render small/simple, performance usually won’t be noticeably slow.
If your layout is static and you don’t really care about SEO, iframes aren’t a bad choice.
Ajax:
Ajax solves the SEO issue. It provides better error handling and remediation. Since the fragment gets loaded directly into the DOM, the page flow is more natural. Ajax has been around for a while and most Web developers are comfortable with it, which means it is fairly easy to implement and maintain.
Because it is asynchronous, initial loading can introduce latency. Updates also require a call back to the server; this can be an issue for applications that require a highly responsive user experience. Ajax it lacks the isolation of an iframe.
If your content is relatively static and you are generating your markup server-side, Ajax is a good solution.
Component:
At the time of this writing, ES6 Components are supported by all modern browsers and most major frameworks support Components. Components are a robust method for client-side rendering of highly responsive Micro Frontends. Coupled with the Shadow DOM, they provide strict isolation and prevent style bleed.
Perhaps their biggest drawback is that they require client-side JavaScript to work. Which means they are not compatible with server-side composition.
In upcoming posts we’ll take a deeper dive into each of these methods, and I’ll provide example implementations of each.
Martin's Tech Corner 