Micro Frontends in JavaScript

What is a Micro Frontend?

It extends the concepts of micro services to the frontend world. The current trend is to build a feature-rich and powerful browser application, aka single page app, which sits on top of a micro service architecture. Over time the frontend layer, often developed by a separate team, grows and gets more difficult to maintain.

What problem is it trying to solve?

• Micro Frontends are a good way to break your frontend into smaller pieces making it easier to develop and deploy
• Allows multiple teams to be contributing to an application without adversely affecting other teams.
• Micro Frontends can also speed up deployment time and reduce downtime for users, as only parts of the application are getting updated at any one time.
• This simplification allows for ability to do more frequent builds.

Pros of Micro Frontend

• Incremental Upgrades
• Simple, Smaller, Decoupled codebase
• Independent deployment
• Autonomous Teams
• Be Technology Agnostic
• Isolate Team Code
• More scalable
• Ability to upgrade, update, or even rewrite parts of the frontend in a more incremental fashion than was previously possible

Micro Frontend Diagram

Different frameworks for each component

One common framework for all

Benefits over Monolithic Approach

Separate Teams for Frontend, Backend

Separate Teams based on Component

Benefits:

• Each team is cross functional (they can work on both frontend and backend tasks)
• Resolves issues of ‘Conflicting Priorities’
• Improves communication and quality
• Ensures consistent focus on the customer experience
• Iterate quickly
• Improves alignment and use of resources.
• Leads to greater innovation.

How is it setup?

OPTION 1: Hybrid Approach

Uses a single container app, composing each micro frontend as a npm package.

OPTION 2: True Micro Frontend

Hosts each micro frontend separately (similar to pages in a website) where each knows the URL (integration points) with parameters to navigate to the other.

Pros & Cons of Hybrid Approach

Pros:

• Easy to implement, just move code over to its own repo.

• Easy to switch over existing monolithic frontend.

Cons:

• The whole app must be redeployed for any changes.

How is this setup?

• Whole UI runs on a single port.
• When updating components you just need to update the version for the component in the package.json file.
• Then, the whole app will have to be rebuilt, retested, and redeployed every time even for small changes.

What is in a NPM Package?

Included in NPM package:

• dist
• package.json
• README (optional)

NOT Included in NPM package:

• Tests
• Node_Modules
• Mock Servers
• Fixtures
• Anything else not listed in above screenshot

Pros & Cons of True Micro Frontend

Pros:

• Only components that have changed need to be redeployed.
• Deployments are faster and simpler.

Cons:

• More processes and ports to monitor.

How is this setup?

Here we pass in the URL and Port, the component is running on as an env variable.

Then, use the Micro Frontend Component to render that component on the screen.

Next, add a new route when you add a new component.

If we update one component only that component needs to be rebuilt, tested, and deployed.

Notes on Optimization

• You will likely have to make changes to how the app is bundled.

How Does CI/CD Work?

• Each component is responsible for its own pipeline.
• Each should build, run tests, and deploy independently of all other components.
• Each component should be able to be run independently.
• For Hybrid Approach it should push new version to NPM.
• For True Micro Frontend it should build and deploy to server on its port.

Common Utils Packages

• Provides a common way for displaying UI elements like tables, forms, charts, etc.
• Ensure components look and act the same across the application
• Speeds up development
• Improves cross team collaboration

Common Mistakes

• Dividing micro frontends too finely, without regard for teams, features or the application’s user experience.
• Not identifying the micro frontends we expected to create upfront.
• Picking a framework that is not intended to support a micro frontend architecture.
• Switching features from the old application to the new as needed to alter them, rather than upgrading the application in a planned, organized fashion.
• Proceeding without having a plan for how to structure our shared libraries or determine what we should or shouldn’t share between micro frontends.
• Splitting app into more teams than you have staff for.

Concerns about Micro Frontends

1. Sharing packages so bundles aren’t huge

• In Hybrid Approach, as long as packages are using same dependencies, it should not add to build size.
• In True Micro Frontend, each component is built separately and has its own dependencies included.
• Different versions of the same package can lead to multiple downloads

Webpack Analyzer is a good tool to look at package sizes

2. Sharing Data Between Micro Frontends

Non-Shared Application State

You need a shared API layer that can cache api objects. What we realized is that a lot of the state that needs to be shared between child applications is just API data. The UI-state that isn’t in the API is much less commonly shared.

So using the ajax library allows the child applications to fetch data from the server like normal, but sometimes the data is actually cached and an ajax request isn’t really made. This way, the child applications don’t even need to know if any other child application is fetching the same data, they just make the API request like normal and that ajax library takes care of not making too many ajax requests to the same endpoint.

This solves a surprisingly high percentage of our data sharing needs.

3. Common Styling

• A common style guide should be provided so each team is aware of styling guidelines.
• Common utils package with commonly used components greatly improves styling consistency.

4. Sharing Common Components

• Is done by creating stylized packages and pushing them up to NPM.
• You should create commonly used components, like Tables, Charts, Forms