Overview
Alright, ready to dive a bit deeper? In this article, we’re going to tackle the tools and tactics that you can use to build your very own micro frontends architecture. We’ve got a couple of big categories to delve into, so let’s buckle up!
First off, we’ll explore the realm of micro frontend technologies and techniques falling under the ‘separate runtime‘ banner. These bad boys allow your micro frontends to run independently, completely sequestered in their own memory space. This makes for a smoother ride with less hiccups from conflicting variables across your micro frontends. We’ll kick things off in this category by examining the concept of micro apps and how they can be leveraged in your micro frontend applications. After that, we’ll take a peek at Iframes and how they can be harnessed for your micro frontend needs.
Next, in the next article, we’re going to transition to the world of ‘shared runtime‘. Here, your micro frontends work in harmony within the same process, sharing a memory space. As you can probably guess, this approach brings its own set of unique challenges, such as resource sharing, memory management, and avoiding conflict between versions, frameworks, and overlapping variables. Within this landscape, we’ll first explore the role of web components as enablers for your micro frontends. Then we’ll switch gears to framework-based components and see how they can be utilized in a micro frontends architecture. To wrap it all up, we’ll explore a technique known as ‘transclusion’ for developing our micro frontend applications.
Throughout this discussion, we’ll apply the micro frontend design principles we’ve discussed in earlier modules to evaluate the effectiveness of each of these techniques and technologies. So, let’s roll up our sleeves and get into the nitty-gritty of implementing a robust micro frontends architecture!
Micro Apps
Hey there, so we’re about to dive into our first method of creating micro frontends, which is a cool technique called micro apps. Picture this: each micro frontend application is its own separate little universe, completely developed apart from the others. That’s what we’re talking about here – total isolation, or separate runtimes, if you like jargon.
Imagine each micro frontend as a mini application of its own. When you navigate between these micro apps, you’re actually switching between independent applications. Sounds confusing? Don’t worry, it’ll feel like you’re still within the same app, because the look and feel remains consistent thanks to shared themes, styles, and UI resources. You can even share these resources centrally, say, using a CDN.
For single-page application (SPA) fans, each micro app is its own SPA. Clicking a link will load an entirely different SPA in your browser. Sharing components, like a common navigation bar, across all micro apps can further enhance that feeling of being in a unified application.
One thing to be aware of is the maintenance of these shared components to avoid unnecessary specific adaptations to one particular application. Another important thing is the single sign-on. Once you’re logged in one app, you’re logged into all of them, so you’re not constantly hitting a login wall when switching between apps.
Applying the same logic to mobile apps is trickier, though. Each operating system presents its own set of challenges and might make it more apparent that you’re switching between different applications.
So, how well do micro apps align with our micro frontend design principles? They hit the mark on being autonomous features – each can be changed, deployed, and they are completely isolated. Communication between micro apps can be achieved using links or through background microservices.
In terms of team ownership, a team can fully own the micro app, from frontend to backend. Being technology agnostic is another score – you can use any technology you like for the frontend and backend.
The challenge, however, comes in the user experience. While we can create the illusion of a single unified application, there will be instances where this illusion falls short. Let’s say, in a shopping website scenario, having to switch to a separate page just to view your shopping basket isn’t an ideal user experience. Sometimes, you just want different micro frontends to show up on the same screen, which is a bit of a challenge with this approach. The key downside to this method is that it somewhat disrupts the user flow and may end up with the user serving as the integration mechanism between different micro apps.
However, the method still has its merits. Each micro app is value-driven, designed to deliver one specific feature to the customer in an optimized way, controlling the entire architecture from frontend to backend. Plus, each micro app can be powered by its own set of dedicated microservices.
Iframes
Let´s now review another tool in our micro frontend scenary: iframes. Iframes are similar to micro apps in that they run in separate runtimes, which helps eliminate conflicts related to shared resources, overlapping variables, or versioning issues between different frameworks and libraries.
Here’s the coolest thing about iframes: they let you run all your micro frontend applications on one webpage, providing an even better illusion of a single, unified application. The main drawback, though, is that they’re web-based. So, for mobile apps, you’d need something like PhoneGap, which allows you to utilize web-based technologies.
Just like micro apps, each micro frontend in an iframe is an independent application. It can be loaded from any web server into an iframe sitting within your main base application or HTML page.
In terms of design principles, the good news is that iframe-based micro frontends are utterly autonomous. Each one is an encapsulated app that can be modified and deployed independently without breaking the others. The not-so-good news? Sharing resources with the base application and other iframe-based apps is a tough nut to crack. You might need a centralized CDN system for sharing UI-related resources.
For communication between micro frontends within iframes, you can use either window events or background microservices. Just like before, team ownership remains untouched – your team can still take full control of the micro frontend application end-to-end.
Another feather in the iframe cap is technology agnosticism. Because of the separate runtime, you can use different frameworks for each micro frontend as they’re encapsulated within their iframes. This prevents any clashes between framework types, versions, or variable names in the global space.
An added bonus is that iframes are a mature technology with virtually universal browser support. While the user experience with iframe-based micro frontends is typically better than with micro apps (since all micro frontends can be on the same page or screen), watch out for any sizing issues that might lead to pesky scroll bars around the iframe.
Performance is another area to keep an eye on with iframe-based micro frontends. If you have many micro frontends on a screen, each with its own runtime and JavaScript framework, you could run into performance issues. Thus, thorough testing for performance is crucial to ensure a solid user experience.
Despite these challenges, iframe-based micro frontends can deliver better value than micro apps. This is because all your micro frontends are on the same screen, and each can be independently developed end-to-end to provide a specific function or value to the customer. As with micro apps, each iframe in our micro frontend architecture contains a micro app, which essentially extends the functionality of a backend microservice.
In the next article we will analyze the techniques for “shared-runtime” approach
That´s all, happy building !