Skip to main content

Micro-Frontend Technology: A new method for creating web apps

IMG 2605

Innovative approaches and technologies are continually evolving in web development. Micro-frontends are one such method that has recently attracted the interest of front-end developers. 

Breaking down a big monolithic front end into smaller (micro) components is a new method for creating web apps: Micro-frontends are small pieces of code that manage specific responsibilities for the entire software, being a section of a webpage’s code. 

Each component is created and used separately. Not tied to a single codebase, the micro-frontend approach allows faster development times and easier maintenance. Using APIs, micro-frontends communicate with one another. Many different technologies and frameworks can be used to develop them. 

 

How we are using micro-frontends to accelerate our business 

Blip, as part of the Flutter Entertainment Group, is looking to adopt micro-frontend technology across all sports platforms. As a global group, we have several distinct products that need a consistent design interface, way of working and user experience. With this in mind, we want multiple teams to contribute faster and to be able to reuse content while building the same apps, so that what changes is configuration, not code. This allows, for example, to reuse events search UI instead of fully developing it each time. 

 

 

What is so good about it? 

Easier coordination among teams 

Coordinating and delivering updates simultaneously can be challenging when different teams are working on distinct features for the same product. With micro-frontends, each team can manage their deployment process without affecting other teams who might be testing out experimental code concurrently. This makes it possible to carry out releases and updates with features that are already live in a more planned and effective manner. 


More time to build new features
 

As micro-frontends allow code reusability and sharing, teams can focus on creating new features instead of duplicating what has already been done every time it is necessary to implement a common functionality. This allows faster feature rollout. 


Flexibility and independence
 

This kind of architecture for creating front-end apps gives front-end teams the same flexibility and speed that microservices give back-end teams. This happens by segmenting a web application into several modules or individual functions and implementing them independently. This independence allows teams to work on their components without depending on others and stops tight coupling. 


Easier maintenance and testing
 

As micro-frontends reduce duplication across applications, they are easier to maintain long term when changes need to be made. They allow developers to work with smaller and more manageable apps, which reduces testing time. 


More efficient performance
 

To load all elements of a page, traditional web development frequently needs several requests. This may not be efficient if some parts are not required for rendering some pages. To improve performance, it is possible to postpone loading these additional modules until they are needed by using micro-frontends. At the same time, using micro-frontends increases fault tolerance since the system is not ruined when one of the components fails. 


Connection to back end
 

The host app allows connection to the back end as it can provide a set of capabilities that the component apps can use. This is another advantage of the micro-frontend's architecture since it is possible, for example, to handle back-end streams to provide live data. 

 

 

Principles that should be followed when using micro-frontends in UI development: 

  • One host app for multiple component apps; 
  • Minimal dependency: development, infrastructure and deployment processes are independent. There are only dependencies in the runtime, which is inevitable if the apps need to communicate with each other; 
  • The host app is a distinct, standalone app that orchestrates its children, so it should be built and maintained independently. Only standard tools should be used so that developer churn does not affect maintenance long term; 
  • The team creating the component (children) app should be free to use any setup and/or framework technology they choose, entirely independent from the host app; 
  • Component apps should be allowed to use their framework version and not depend on the host version;  
  • To integrate apps in the front end without having to go through back end for simple communications, a message-based communication mechanism needs to be implemented between the host and the component apps. 

 

 

Micro-frontend using iFrames 

iFrames make it simple to load several applications inside the browser and to create a page consisting of separate sub-pages due to its inherent structure.  

At Flutter, we have concluded that iFrames satisfy all the micro-frontend critical technical requirements: they are well-established, and their native technology is completely independent of component apps. The integration via the window message Web API offers the least dependency, and it requires minimal reworking to move to a different solution. 

 

How are the host app and its child applications integrated? 

It is required a configuration file with child app definitions determining their URL to load the child app bundles into iFrames. The micro-frontend lifecycle is a strategy for negotiating child apps mounting onto the main window for actual use. It is the cycle any micro-frontend component app needs to undergo during its life inside the micro-frontend host to be properly integrated into it. This is a standard protocol that all component apps need to obey, and the host needs to honour. The host app first renders an iFrame that loads the child app in a 3-step protocol that leverages the inter-app messaging system: 

  1. The child app (running in its iFrame) messages the host to inform it is now mounting. 
  2. The host app replies with authentication/authorisation data.
  3. Based on the auth/auth data it received, the child app replies with:
    a) Mounted: the child app is now part of the micro-frontend app and can be used.
    b) Unmounted: the child app refuses to mount, and it is expelled from the host.

 

 

Implementation status at Flutter Entertainment Group 

For the time being, we at Flutter are in the experimenting and learning phase of the micro-frontend's implementation process. As soon as we finish this phase and figure out what works best for our teams, we will certainly be reaping the advantages of this approach for front-end development. 

 

Blog Placeholder WRITTEN BY:
Soraia Gonçalves

Related Articles

Cheltenham 31

Behind the Tech Scenes: Prep for Peak Event Performance

Introduction This article explores our preparations and strategic initiatives during major sports events, focusing on how we ensure peak performance and customer satisfaction. We will discuss the meticulous planning behind our technical operations,…

View More
Blip 23

Together for a better internet

Across the world, around 200 countries celebrate Safe Internet Day, dedicated to making the online space a better place for children and young adults. We can proudly say that this European initiative lived to see its 19th edition and bring…

View More
DSC03135

Mastering Playwright Fixtures: Hands-On Test Automation

Introduction Quality Assurance teams at Blip are constantly innovating to ensure the reliability and quality of our platforms, especially given the dynamic and unpredictable nature of the data we handle...

View More