In the microfrontend part of the frontend world

In the beginning there was chaos. Now we have microfrontends — it’s a joke, but a perfect sentence to start this article with. If you even heard something about micro in the dev world, it was probably a microservice. Are microfrontends and microservices connected? Yes and no, but first let’s check what microfrontens actually are.

The definition of microfrontends

frontend schema
frontend schema

We have separate services connected to one frontend application. The most popular solution which can be problematic in huge projects — difficult to maintain, test and develop. So what in return?

Take a look at what are the most characteristic parts of microfrontends:

  • Each part can be developed independently
  • Each part can be deployed independently
  • Each part can be tested independently
  • Each part can be hosted independently
  • All elements are composed into one whole

Let’s rewrite the above schema to the microfrontends world:

frontend wrapper schema
frontend wrapper schema

Interesting, isn’t it? Take a deeper look at this schema. As you can see, each microservice has a dedicated frontend part in a different technology. What is this blue rectangle above? There needs to be a part which stitches all frontends together e.g. page skeleton, layout, navigation, etc. We can think of this wrapper as an entry point for customers. From a technical point of view this part is the orchestrator for our microfrontends applications. In the best approach it only knows what should be rendered, when and where, it can be a communication layer between other elements and suppliers of core scripts and styles for all applications.

How are the elements delivered to the orchestrator?

The second approach are iframes with each application having its own hosting. Orchestrator renders multiple iframes on the page. In such situation each iframe is a separate thread in the browser so it could have performance advantages. However, styling is more difficult. In an iframe we can not create e.g. sticky header because it’s completely isolated, especially when it’s hosted on a different domain. Page navigation and routing could be a problematic part, too. Iframe approach is perfect when our application needs something like widgets which should be an isolated part of our page. Perfect example — situation when you need an advertisement placeholder on your page.

MIcrofrontends are not only superlatives

Another difficult area is page styling. We have to create a common way of working for all micro parts. Each part needs to be integrated and styled on the wrapper’s skeleton and be compatible with different browsers, devices and resolutions. Keep responsive web design on microfrontends world needs to be done in the whole application, wrapper and individual applications which can be quite a challenge.

Is microfrontend a solution?

MonolithMicroftontendTeams working in one big projectAutonomous teamsMostly one technologyTechnology dedicated per team or projectIncremental updates could be difficultIncremental updates are easilyHosted in one placeEach part could be hosted in different placeTesting as one projectTesting separates elementsOne big code pieceSmaller code pieces dedicated per functionalityPerfect for small applicationsPerfect for big applicationsEasy routingIn some situation routing is difficult, need to be done on server sideEasier stylingStyling could be more difficultBig project is difficult to maintain and developBig project is easier to maintain and develop

Have you ever seen microfrontend application?

You’re interested in the topic or have some questions? Don’t hesitate to contact our team!

Sources:

  1. https://micro-frontends.org/
  2. https://martinfowler.com/articles/micro-frontends.html

human-centric software design & development. check out our website: www.iteo.com