Introduction to Micro-frontend

In Micro-frontend we divide a monolithic app into multiple smaller apps.

Each app is responsible for distinct feature of the monolithic app.
For example,
An E-Commerce app can be divided into below smaller independent micro frontend apps.

• Products Listing
• Cart
• Shipping
• Payment
• Tracking
• Customer Services etc.

Why Micro-frontend?

• Multiple teams can work in isolation dedicated to one MFE app.
• Code reusability is very high.
• Each team is free to choose their own technology (React/Angular/Vue), deployment, development strategies etc.
• If one app is down, rest apps can still work.
• Each MFE app is smaller so easy to understand and make changes.

Monolithic Vs Micro frontend App Architecture

Monolithic App :- All features of web-application in a single app.
Micro-frontend App :- Each feature is managed by an independent MFE app i.e.
MFE #1 is responsible for App-bar.
MFE #2 is responsible for Products-List.
MFE #3 is responsible for Side-Nav bar.
Container App is responsible for coordinating between these MFE apps.

How MFE apps integrates with each other

1. Build Time integration (Compile Time integration)
2. Run Time integration (Client side integration)
3. Server Side integration (SSR integration).

Build Time integration (Compile Time integration)
In this integration, container app has access to all MFE apps source code and a combined bundle is created when Container app is build / compiled before loading in browser.

Pros

• Very simple to setup and understand.
• MFEs can be lazy-loaded to improve performance.

Cons

• Container app needs to be rebuild and re-deployed every time any changes are made in MFE npm package.
• If multiple MFEs will be tightly coupled with Container app then there are chances that an MFE app will become a distributed monolithic app.
• In short your MFE is integrated with container app similar to an NPM package.

How MFE apps integrates in Build Time Integration (here taking example of an E-commerce application)

1. Team #1, develops Products-List MFE app.
2. Team #1 deploys Products-List MFE app and publish it as an NPM package.
3. Team #2, managing container app, includes Products-List MFE app as an NPM package dependency in container app.
4. Team #2, compiles and builds container app bundle, this bundle contains code of Container app including Products-List MFE app code as well.
5. In short your MFE is integrated with container app similar to an NPM package.
6. That’s it.

Run Time integration (Client side Integration)
In this integration, Once container app is loaded in browser then it can access MFE apps by using urls of MFE apps.

Pros

• Each MFE can be deployed without re-deploying container app.
• Different version of same MFE app can be used, container can decide which MFE version to use and when, it makes testing and integration easy.
• Each MFE app can have their own tools and libraries for development purpose.

Cons

• Run Time MFEs are more complex to setup and integrate than build-time MFEs.

How MFE apps integrates in Run Time Integration (here taking example of an E-commerce application)

1. Team #1, develops Products-List MFE app.
2. Team #1 deploys Products-List MFE i.e. https://mystore.in/productslist.js
3. Team #2, managing container app, will use webpack-module-federation to integrate it with container app.
4. When user opens https://mystore.in/ , container app is loaded in browser and fetches Products-List MFE app and displays it in a defined location in container-app page.
5. That’s it.

Serve Side Integration (SSR Integration)

In this Integration Micro-frontend app works in similar way as SSR components works. All MFEs apps are integrated at server end and a composited container app is returned to browser.

Pros

• App loads faster.
• SEO friendly approach.

Cons

Limited interactivity.
Development challenge.

Thats it for now, Thank you for your time.