Micro frontends is an architectural idea where you apply ideas from micro services to the frontend or UI code. The aim is to split the application into many separate parts, which can evolve and be managed individually. The split is done based on user facing features of the site instead of the traditional way of splitting based on technical skills (frontend vs backend). Each part is as stand-alone as possible and covers the full stack from the UI in the browser to the database on the server. This makes it possible for separate teams to own separate parts without constantly stepping on each others' toes.
In this Vaadin Labs experiment, we have built an IoT dashboard application where you can set the heating for a flat and monitor energy usage and temperatures in different rooms. The application is a micro frontend and has been split into the following parts:
App |
Floorplan |
Room-info |
The main application connecting everything
|
The floorplan view separated out to a separate project | A reusable web component created in Java.
|
The floorplan view could be handed over to another team while the initial team maintains control over the main application, containing all other views. Should the need arise, other views could be split out the same way as floorplan.
Each part is built as a separate Vaadin project and produces an individually deployable WAR file.
| With a small example like this, splitting out parts can be seen as just extra overhead. Think big. |
Additionally there are two technical parts included to deal with the component set (aka design system) used
Components |
Bundle |
| Includes all components used in the project. | A minified JavaScript bundle needed for the components to work in the browser. |
These two are updated only if you introduce new components into the project.
When your application is a Java monolith, you can communicate using any of the methods available in the Java world (event bus, pubsub channels, direct method calls, dependency injection etc). In this micro frontend application we have chosen to do communication between the parts in the browser through events and element properties. This makes the WAR files for each part truly independent as there is no connection on the Java/server side. This also allows using different frontend technologies for different parts of the application although not shown in this example.
Listed among the core ideas of micro frontends on https://micro-frontends.org/ is among others to "Be Technology Agnostic" and "Isolate Team Code". In this case we have chosen the pragmatic approach and assume that all parts of the application is built with the same components. By doing this, we can use the same component bundle for all parts of the application and avoid two problems:
Different versions of the same web component (tag) cannot be used at the same time in the browser
Loading the same components over and over again for many views is bad for performance.
From a design/UX standpoint, this keeps the application consistent. You can think of the component bundle as part of your design system.
We can still add new views or components using other approaches as long as we use the same components. If you want, you could convert the Java web component (<room-info>) to a web component implemented using e.g. Lit.
The example application is deployed at https://labs.vaadin.com/iot-app/.
As a user of the application, you should not be able to tell that it is built as a micro frontend.
To better understand what micro frontends mean, have a look at the source code in GitHub: https://github.com/Artur-/iot
Are you interested in micro frontends or are you perhaps already using this architecture? Do you have multiple teams working on the same application? Share your insights below!