From spaghetti to lasagna to ravioli

In an interesting post about bare metal monolith and serverless microservices in AWS cloud Benoit Hediard, founder and CTO of Agorapulse, described an insightful and somewhat humorous analogy of the development of software architecture over the decades with Italian cuisine. I would like to mention these here in order to give the topic of so-called micro-frontends the necessary framework.

Imagine if you could describe the last three decades of evolution in software architecture with three different Italian specialties, you would probably come across the following three, just like Benoit Hediard in his analogy:

• 1990s: The Spaghetti-oriented architecture, also known as Copy & Paste
• 2000s: The Lasagna-oriented architecture, also known as the layered monolith
• 2010s: The Ravioli-oriented architecture, also known as microservice network

Benoit is looking forward to another Italian dish in the next 10 years. In his case, he is speculating on a pizza. I am not sure what he meant by that, but I am sure that the microservice principle could and should be used not only in the backend, but also in the frontend. This brings us to the question of what a micro front end is anyway.

Finally, here is the original picture (source) for illustration.

Now back to the age of ravioli, by now everyone should have heard: Microservices are a great thing! They are lean, fast, independent in their actual implementation, technologically up-to-date and are usually placed in container orchestration software such as Kubernetes, ideally hosted by one of the large cloud providers. Unfortunately, the microservice trend is still too limited to the backend & middleware world, but mostly the frontend still is, please excuse me in advance if I dare to say that, the old confessed Monolith.

Wouldn’t it be great if the front end could also be split up into slim, small, independent parts? Or, to put it another way, if the frontend has similar standards and a low threshold as in a microservice-oriented backend? This is exactly the question we are looking into in today’s TechUp about micro-frontends and their benefits.

What exactly is a micro frontend?

In short, a micro front end is a single, isolated part of an entire web application. These micro-frontends can be called up in isolation, but usually do not contain any basic standard components such as a header or a footer, but only the specific, technically limited functionality of a single page.

This can best be illustrated with an architecture diagram as follows. In a front-end architecture, there are any number of front-end modules, each of which can be implemented with the framework of choice. Here, for example, we see an Angular module in red which is rolled out on Prod via its own CI / CD. The same applies to React (blue) as the second and here Vue.js (green) as the third module. These modules are then put together in the shell as a wrapper, implemented in our illustrative example in Svelte (orange, right), and made available to the user as an aggregate.

It is best to divide the entire application page structure into logical, functionally separated components, and in a second step define separate, domain-specific sub-applications. These sub-applications, the micro front-end modules, are then transferred via a separate repository with an independent CI / CD process and, if necessary, also hosted separately. In this way, each module can be further developed, built, called up, and ideally also automatically tested individually, in isolation.

The so-called shell acts as a wrapper, which aggregates all micro-frontend modules and makes them fully available to the customer as a seamlessly usable web application. This process of merging is also called UI Composition in technical jargon.

As already mentioned at the beginning, it is very important here that it does not matter which technologies are ultimately used in the individual micro-frontends. For example, the wrapper can be an Angular project by integrating a React, a VueJs, a Svelte, and a SvelteKit project. The wrapper, as well as the actual micro-frontends, do not necessarily have to use a framework here; the wrapper could alternatively be an e-commerce system such as Shopify or SAP Commerce, which calls up different micro-frontends and embeds the user in its presentation.

In summary, one can say that the benefits of micro-frontends have the same advantages as microservices in the backend. The most important advantages would certainly be the following:

• be slim on the way
• to be technologically independent
• have no legacy systems or issues
• being able to choose and use the best possible and most up-to-date technology for individual parts
• have separate CI / CD & testing cycles of individual frontend parts
• Feature oriented teams, e.g. a “product team”, which is responsible from A-Z for the product database, the interfaces and for the product part in the front end and develops this further

Depending on the type of micro front end, the responsibilities differ; routing is sometimes done in the shell or directly in the micro front end. So let’s take a quick look at the most common implementation variations of a micro-frontend-oriented architecture.

Implementation proposals for a micro-frontend environment

The simplest type - the hyperlink

The simplest of all solutions is the classic hyperlink, which points to a completely different application, for example a single page application. Unfortunately, the user loses his application state here, the application has to be completely reloaded. Thus, a seamless and consistent user experience cannot be guaranteed. But this is also a kind of micro-frontend, for example a new page could be implemented in other technologies such as the existing pages.

A classic, very large example of this would be the Google Suite, with each app such as Gmail functioning as its own micro-frontend and these are connected via hyperlink.

The classic way - the iFrame

A second, common way to operate MicroFrontends is the well-known iFrame. This can be used to integrate another website at a specific point, creating a completely encapsulated, separate DOM. In practice, this solution often encounters a suboptimal user experience. Typically, the scrolling behavior changes in an unfamiliar, unintuitive way and the expected responsiveness is usually no longer given.

Basically, however, this somewhat outdated approach certainly has an area of application and its reason to exist. Just not very elegant.

The modern way - the web component

The third variant is certainly the optimal one and should be the way in which a micro frontend should be integrated. The aim is to divide the HTML pages into reusable components, so-called web components.

Web Components were standardized back in 2012 and are now virtually supported by every browser. By loading JavaScript files, you basically teach the browser new elements, which it can then render.

If you take a closer look at this type, there are three quintessential web technologies:

• Custom Elements: this allows custom components including functionality to be defined, created and used, this is a modern browser standard
• Shadow DOM: This encapsulates the DOM of the WebComponent and is not influenced by the actual DOM of the page
• HTML template: this can be used to write markup templates, e.g. B. Fill data dynamically

It is important here that the name of the component must always contain a hyphen. Technically, there are different frameworks that can create web components, we want to take a closer look at Angular Elements today.

Classic with an Angular-based micro frontend

Now let’s look at the happy case with Angular. We look at how you could build a micro-frontend with Angular.

First we have to adapt the Angular compiler so that the package ngx-build-plus is used. This allows us to pack the complete application into a large main bundle. The whole magic then happens in AppModule, there the custom element is created and defined. It looks like this:

1
2
3
4
5
6
7

    import {createCustomElement} from "@angular/elements";
    
    ...
    constructor(private injector: Injector) {
        const el = createCustomElement(SearchResultPageComponent, {injector});
        customElements.define('b-nova-homepage-search', el);
  }

Here we use the package Angular Elements to release our SearchResultPageComponent externally via the element name b-nova-homepage-search. It is important here that only Angular components can be used that were previously defined in the bootstrap part.

Furthermore, Angular has to be specially configured so that the compiler does not make Output Hashing of the files in order to be able to always include them with the same name. Now we can integrate the JavaScript in any web application and integrate the micro-frontend via our custom HTML tag.

1
2
3
4
5
6

<b-nova-homepage-search></b-nova-homepage-search>

<link rel="stylesheet" href="<url to micro frontend>/styles.css">
<script src="<url to micro frontend>/runtime.js" defer></script>
<script src="<url to micro frontend>/polyfills.js" defer></script>
<script src="<url to micro frontend>/main.js" defer></script>

As can be seen here, we also bind the CSS and JS in the shell; here, too, there are other options for the micro frontend to attract its required dependencies itself. In this case, the complete Angular context is now included in the micro frontend. Here, too, there are other options depending on the application, e.g. B. to use the Angular Context of the shell.

Of course, you don’t have to host the micro frontend separately, e.g. pack with.

Real World Micro Frontend

Did you notice? We already have a micro frontend in productive use and we have already used it for customers! 🚀

On our homepage we have outsourced the search functionality to an Angular Micro Frontend. The header, the navigation and the footer come from our Magnolia CMS, the actual functionality of the page comes from our micro frontend. We claim at this point that the use of a micro frontend a user does not notice, feel or see, because the UX, the scrolling behavior, etc. is identical to a normal web app.

This division also allows us to implement small parts of an existing web application with newer technologies without having to migrate the entire project. So we will probably implement the next micro-frontend with Svelte or something similar.

Why exactly rely on micro frontends?

A huge advantage of the ravioli architecture in the front end is the sustainability and the possibility of being technologically independent for further developments and new developments. Imagine you are currently using a CMS system and want to modernize a small component in it. The use of a modern front-end framework would make sense. Without web components or micro frontends in general, you would have to migrate the entire project or laboriously ’tinker in’ a framework.

With the use of micro frontends, you can adapt, expand or modernize existing applications. This approach is also recommended when starting a new project, as you can evaluate and use the right product or framework for every application.

In addition, it is an incredibly lean and cool thing to work ‘feature oriented’ in the frontend, to have a lean CI / CD process with automated tests and to move away from the monolith.

Do you need support with your web application or do you want to start a new project with future-proof tools?

Contact us, we’re glad to help!

This text was automatically translated with our golang markdown translator.