Micro Frontend – The Final Step. Part III

14 July 2021


We start the last chapter by discussing the design approach, the micro-frontend implementation, and the capabilities it offers.

All of the information we found in the three articles on micro-frontend should be treated as a serious introduction to the topic.

I present a short summary to remind you of what you already know:


CategoryExample implementationStrengthsWeaknesses


Build-time packagesBuild-time integrationNPN, yarn

Easy to setup – no additional tools needed

Known to developers

Code deduplication

Easy to achieve UX consistency

Lockstep release process – the whole bundle must be recompiled and deployed

Limited to one framework

Use only for small projects (no more than three teams) only if other options seems to be to much complicated
SSI/ESIServer-side integration

SSI – NGINX, Apache Http

ESI – Varnish, Squid

Easy to setup – HTTP servers and cashes are part of every web application architecture

Full independency of deployments 

Lack of cross-component communication – it must be solved in another way

Hard to achieve consistent UX look & feel

Lack of build in authentication and authorization

Use for eCommerce like web applications when microservices with less fluctuating application and services architecture
Specialized micro frontends middlewareServer-side integration

Zalando’s Mosaic, 

Compoxure, micro-fe

Full independency of deployments

Excellent control over page performance and failover

Built-in advanced dynamic routing with autodiscovery

Hard to setup – requires additional components

Lack of cross-component communication – it must be solved otherway

Hard to achieve consistent UX look & feel

Lack of build in authentication and authorization

Use for eCommerce like web applications when microservices with high fluctuation of application and services architecture
IframesClient-side integration

Easy to setup – no additional tools needed

Full independency of deployments

High component isolation

Cross-component communication

Real framework agnostic  

Hard to implement deep-linking

Hard to implement RWD

High resources consumption 

Use when framework agnostic and component isolation is the key concern and UX is not so important
Micro frontend frameworkClient-side integrationSingle SPAFull integration between micro frontends and container application

Support for all major JS frameworks

Lazy loading

Not well documented engine

Use in rich application composed of many communicated micro frontends



As a conclusion, let’s take a look at a rather interesting diagram that summarizes the possibilities of implementing a project using a micro-frontend architecture approach Iframe:

  • Build-time composition.
  • Server-side composition.
  • Client-side composition.
  • Route composition.





We have mentioned some of these opportunities in recent blog posts.

A rather interesting but old alternative is to choose the implementation as Iframes.

Of course, everything has its advantages and disadvantages.

One undeniable disadvantage when choosing this type of solution is the security level.

a man is writting some programming code

This solution will not work in large advanced projects on which teams of programmers will be working, it is rather an addition, an opportunity to do some home project to improve your skills or familiarize yourself with something that has already existed for a long time.

Another issue with choosing this solution is cookie sharing, it only works if your internal spa is on the same domain. And last but not least, apart from the problems of maintaining a common language, styling or proper management of mechanisms that are found in downstream components.

Sometimes when we want to display an external page we may get an error of being able to display it as an iframe: “refused to display a frame because it set ‘X-Frame-Options’ to ‘SAMEORIGIN’“.

If the site is in our domain or we have the ability to change the configuration, it is enough to change it (of course, depending on the environment we use and technology).

On apache to edit security.conf:

nano /etc/apache2/conf-enabled/security.conf


Header set X-Frame-Options: “sameorigin”

enable mod_headers:

cd /etc/apache2/mods-enabled
ln -s ../mods-available/headers.load headers.load

restart Apache:

service apache2 restart

Let’s look a sample code:



     <iframe src=""></iframe>



The above-mentioned code will make it possible to display a document (in this case the page” embedded in the main HTML document.

With this approach we can display other external sites like youtube on our HTML page.

If we wanted our other HTML documents from the same domain to be displayed in the iframe, we would do this using the event bus implementation and Message Event (communication between window object):

We can use ready-made libraries that extend the capabilities of iframes e.g. for React we have prepared a library:

import Iframe from 'react-iframe'.

<Iframe url=""








url (required) – string the iframe url.

All other attributes are optional:

src – string if set, overrides url.

scrolling – string not set if not provided (deprecated in HTML5).

overflow – string default to “hidden”.

loading – string (not added to DOM if not provided).

frameBorder – number default to “0” (deprecated in HTML5).

position – string (not added to DOM if not provided).

id – string if set, adds the id parameter with the given value.

className – string if set, adds the class parameter with the given value.

display – string defaults to “block”.

height – string (1px > any number above 0, or 1% to 100%).

width – string (1px > any number above 0, or 1% to 100%).

allowFullScreen – if set, applies the allowFullScreen param (deprecated in HTML5). If set, adds allow=”fullscreen”.

sandbox – add optional sandbox values (“allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts allow-top-navigation”).

allow – add optional allow values (“geolocation microphone camera midi encrypted-media & more”).

styles – add any additional styles here. Will (intentionally) override any of the props above. 

Summary: Iframes are the HTML documents that can be embedded inside another HTML document.

two men are programming


We are coming to the end of this series that introduced us to the world of the micro-frontend approach. Our journey is not over, it is just beginning. It is time to put the knowledge and skills we have acquired into practice. Remember also that approaching the solution architecture in this way is not good for all projects and challenges. A prudent and responsible approach to architecture design with or without the use of micro-frontend is certainly recommended and desirable.

We will certainly see in other interesting series about the world of IT, programming or interesting mechanisms, approaches to creating architecture solutions.

I send interesting positions on which you should have a look, they will give you a different perspective on the subject and broaden your knowledge and make our skills in the approach in the architecture of micro-frontend definitely increase.


Rafał Czarkowski
Rafał Czarkowski
Over 12 years as a solution architect, technical team leader, full-stack developer, passionate about new technologies, solution architecture and long talks about the approach to programming.
Read my other articles

logo stopka
Copyright ©2024, Evertop Sp. z o.o. | Privacy policy
scroll to top