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
Previous applications were created as monoliths. To make it simple — it was one project hosted as one application and often developed in one technology. Take a look at this simplified schema, how the monolith frontend looks like in a microservice application:
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:
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?
There are a few approaches but the most popular ones are custom elements and iframes. If we think about custom elements, we think about script which provides the code of microfrontend application rendered on page by custom html tag. There are a lot of advantages of this approach, e.g. styling or using shared elements are easier. However, scripts could be really large which may cause some performance problems.
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
The entry threshold is high and it’s difficult to create a perfect orchestrator. The hardest part is routing, especially when multiple microfrontends apps on the same landing page need to call an url. It’s easier when one app is on one subpage, because the whole responsibility of navigation can be passed to the server. Routing is the hardest part of microfrontends application.
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?
No, it’s an approach not suitable for each application. Decision whether to use it or not should be done before starting a project. You can find projects based on microservices in which microfrontends are useless because frontend is simple or you can isolate context in monolith using libraries and approaches named modular monolith. But if you create complex applications in big teams, microfrontends approach is perfect. Take a look at this comparison of monolith and micrfrontends approaches:
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?
For sure, e.g. Facebook or Allegro. Simple parts of microfrontend could be done in any application actually. Imagine that you are going to create an info service but you need your own advertisement area — weather forecast or custom image taken from your gallery. It’s a perfect world for microfrontend because each part can be a separate app integrated into one. Are you going to create a big shop? Why not use microfrontends — let’s split it to smaller, integrated parts like home page, category view, basket, order etc.
You’re interested in the topic or have some questions? Don’t hesitate to contact our team!
Sources:
