You have 1 free story left this month. Sign up and get an extra one for free.

How To Implement Micro-

Frontend Architecture With
Angular
Everything you need to know about microservice oriented architecture
for the frontend from beginner to advanced

Bhargav Bachina Follow

Jan 10 · 8 min read
 Photo by Jaime Spaniol on Unsplash

Modern web applications are becoming big and more complex and
sometimes managed by different teams. Your application might have
features developed by different teams and you want to release only certain
features into production before delivering the entire application. How do
you manage different teams, different release timelines if you have one
repo?

Most of these complex apps live on the client-side which makes it harder to
maintain. There are some other issues as well with this monolithic big fat
application. In this post, I am going to discuss advantages, disadvantages,
implementation and a lot of other stuff.

Introduction

A Journey Into Mirco-Frontends

Advantages of Mirco-Frontends

Features of Mirco-Frontends

How Do We Split Apps

Different Approaches to Micro-Frontends

Micro-Frontend Frameworks

Example Micro-frontend Project With Angular

Summary

Conclusion

Introduction
Micro-frontends are small applications mostly divided by subdomain or
functionality working together to deliver a larger application. Before diving
into Mirco-frontends, we will understand what are micro frontends and
why we are talking about those.

Usually, projects come in different sizes and different requirements. If your

project is simple enough to have two or three pages and can be maintained
by a single team, you don’t have to think about these Micro-frontends. You
can just implement with any of your chosen framework such as Angular,
React, or Vuejs.

But, this is not the case all the time. Sometimes your frontend app might be
a small part of another big application or your app consists a lot of sections
and features which are developed by different teams or your app is being
released into production feature by feature with developed by separate
teams. If you are in one of these situations then you need to think about
Micro Frontends. Let’s look at it in the below diagram.
 Micro Frontends Architecture

As you see in the above diagram, we have 6 frontend apps working together
to deliver the large application. The communication between these apps
can be done with an event bus, window object, or publish/subscribe
methods. Each app can be implemented by a separate team and any
framework. Each app can talk to their backends or endpoints individually.
There is a bootstrap/launch app that loads all the apps and mounts and
unmounts in the DOM depending on the user interaction or routing.

. . .

A Journey Into Mirco-Frontends

We will first understand why do we need this in the first place. Let’s have a
look at the present technologies that we use for user faced web
applications.

coming soon!

. . .
Advantages of Mirco-Frontends
Here are the advantages of this architecture.

Apps are small

Obviously, apps become small when we split the large application by
sections, pages or features.

Apps are independent

Since all the apps are divided and developed separately these are
independent of each other

Apps are easier to understand

Apps are easier to understand because they are small and developed by a
single team.

Apps are easier to develop and deploy

As these apps are small in nature and developed by a single team its very
easy to develop and deploy. We can even deploy independently.

Apps are easier to test

We have to write thousands and thousands of unit tests for larger
applications and takes forever to run. This makes out deployment process
slower. When it comes to micro frontends each app has few unit tests and
executes its own unit tests and can be run independently.

Apps development becomes faster

The whole development becomes faster and easier because of separate
teams.

CI/CD Becomes easier

Each app can be integrated and deployed separately and this makes the
CI/CD process a lot easier. When we fix the app or introduce a new feature
we don’t have to worry about the entire application since all the features are
independent.

Independent Stacks and versions

We can choose our own stack for each app but this doesn’t happen so often
But, we can have different versions of the same stack. For example, Some
teams have the flexibility and time to introduce and test newer versions of
the same stack.
No Shared Code
In large applications, we tend to share code across features but, this doesn’t
scale well and introduce a lot of bugs and interdependency as the app grows
bigger and bigger. This doesn’t apply with the Micro-frontends as we do not
share the code unless it is a dumb component.

Can change architecture easily without touching old one

Sometimes we have to extend the old architecture but we might not have
the developers to implement or extend the architecture. With the Micro
frontends approach, we can develop the new feature with the latest stack
and deliver independently.

. . .

Features of Mirco-Frontends
Each frontend represents a specific feature or subdomain of the entire
application

Each frontend can be implemented with a separate team.

Each frontend can be implemented with different technology.

 They cannot share logic and its independent of each other.

Each Frontend can be owned by a single team.

. . .

How Do We Split Apps

Let’s see how we can split large applications into micro frontends. There are
no specific criteria to divide the apps and we can separate in a number of
ways depending on our needs. We will see all the possible ways that we
could divide apps.

By Feature
This is the most common method since we can easily divide the features of
the app. For example, if there are three features for the app Dashboard,
Profile and views we can make each feature as a separate app and mounts
and unmounts in the DOM with the help of Launch.js. This Launch.js can
be a separate app or just a simple javascript app.
 By Feature

By Section
Some of the apps have so much functionality with each section, for
example, coinbase, Gmail, etc. We can implement each section as a new app
in that scenario.
 By Section

By Page
Some app’s functionalities are divided by page. Each page has some
functionality that can be independent. We can divide these apps by page We
have four pages in the below diagram. we can make four apps out of this.
 By Page

By Domain
Splitting app based on the domain is also one of the most common
approaches.
 By Domain

. . .

Different Approaches to Micro-Frontends

There are many approaches that you could implement Micro-Frontends.
But I found these 6 ways to implement. Here is an article that I have written
about these.

Iframes

Through NGINX

Web Components/Angular Elements

Angular Libraries

Monorepos

Customized Orchestrator

. . .
Micro-Frontend Frameworks
Micro frontends have been implemented for at least two years and it is still a
green field. Have you ever wonder are there any frameworks or libraries to
implement these and makes our job easier. The answer is yes and there are
a couple of libraries or frameworks

single-spa

frint.js

single-spa
single-spa is a javascript framework for front-end microservices and can be
implemented with all three popular frameworks/libraries such as Angular,
React and Vue.js. It can lazy load the applications based on the need and
You can check out their website for more information.

frint.js
frint.js is a Modular JavaScript framework for building Scalable & Reactive
applications. It doesn’t support Angular yet but it supports React. If you are
building a reactive application from scratch and you are just starting, this is
the framework for you. You can check out their website for more
information.

. . .

Example Micro-frontend Project With Angular

With all this information let’s build an example Angular project with the
help of a single-spa framework. I would like to build a simple app for the
demonstration and I will do the full example with all the features in another
post.

We will split this app by section as shown in the below diagram. We are
going to implement 4 apps in total: HeaderApp, DashboardApp, FooterApp,
and root application.
 Micro Frontends

Here are the four repositories for four apps. You can clone these run
separately on your machine.

// root app runs on port 4200

git clone https://github.com/bbachi/micro-root.git
npm install
npm start

// micro header runs on port 4300

git clone https://github.com/bbachi/micro-header.git
npm install
npm start
 // micro dashboard runs on port 4202
git clone https://github.com/bbachi/micro-dashboard.git
npm install
npm start

// micro footer runs on port 4201

git clone https://github.com/bbachi/micro-footer.git
npm install
npm start

You can access the whole application on http://localhost:4200/

Running all four apps together to make it one app

Here is the micro-root app index HTML file. We are importing all the three
apps on line 10 and registering the apps with the appropriate name and
location. Since we are loading all the apps on page load, we are not defining
any specific context paths.

1 <!DOCTYPE html>
2 <html>
3 <head>
4 <meta http-equiv="Content-Security-Policy" content="default-src * data: blob: 'unsafe-inline
5 <meta charset="utf-8">
6 <meta http-equiv="X-UA-Compatible" content="IE=edge">
7 <title>Your application</title>
8 <meta name="viewport" content="width=device-width, initial-scale=1">
9 <meta name="importmap-type" content="systemjs-importmap">
10 <script type="systemjs-importmap">
11 {
12 "imports": {
13 "footer": "http://localhost:4201/main.js",
14 "dashboard": "http://localhost:4202/main.js",
15 "header": "http://localhost:4300/main.js",
16 "single-spa": "https://cdnjs.cloudflare.com/ajax/libs/single-spa/4.3.5/system/single-s
17 }
18 }
19 </script>
20 <link rel="preload" href="https://cdnjs.cloudflare.com/ajax/libs/single-spa/4.3.5/system/sing
21 <script src='https://unpkg.com/core-js-bundle@3.1.4/minified.js'></script>
22 <script src="https://unpkg.com/zone.js"></script>
23 <script src="https://unpkg.com/import-map-overrides@1.6.0/dist/import-map-overrides.js"></sc
24 <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/4.0.0/system.min.js"></script>
25 <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/4.0.0/extras/amd.min.js"></scri
26 <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/4.0.0/extras/named-exports.js">
27 <script src="https://cdnjs.cloudflare.com/ajax/libs/systemjs/4.0.0/extras/named-register.min
28 <style>
28 <style>
29 </style>
30 </head>
31 <body>
32 <script>
33 System.import('single-spa').then(function (singleSpa) {
34 singleSpa.registerApplication(
35 'header',
36 function () {
37 return System.import('header');
38 },
39 function (location) {
40 return true;
41 }
42 )
43
44 singleSpa.registerApplication(
45 'dashboard',
46 function () {
47 return System.import('dashboard');
48 },
49 function (location) {
50 // return location.pathname.startsWith('/app2');
51 return true;
52 }
53 )
54
55 singleSpa.registerApplication(
56 'footer',
57 function () {
58 return System.import('footer');
59 },
60 function (location) {
 61 // return location.pathname.startsWith('/app1');
62 return true;
63 }
64 );
65
66 singleSpa.start();
67 })
68 </script>
69 <import-map-overrides-full></import-map-overrides-full>
70 </body>
71 </html>

index.html hosted with ❤ by GitHub view raw

root app index.html

You can give /header location path so that the header is loaded when
browser URL navigates to /header. Let’s test it out.

1 <script>
2 System.import('single-spa').then(function (singleSpa) {
3 singleSpa.registerApplication(
4 'header',
5 function () {
6 return System.import('header');
7 },
8 function (location) {
9 return location.pathname.startsWith('/header');
10 // return true;
11 }
 }
12 )

index.html hosted with ❤ by GitHub view raw

with /header

Header only load with the route /header

. . .

Summary
Micro frontends are the implementation of microservices for the front
end
Modern web apps are becoming more and more complex and most of
the code lives on the client-side.

With this Micro frontend approach, we can make it easier to understand,

develop, test and deploy larger applications

There are so many advantages to using this approach. At the same time,
don't use it for every app especially small apps.

Each app can be developed independently, Each app can use a different
stack, Each can be owned by a single team or multiple teams and finally,
they don’t share logic.

It’s tempting to use a different framework for each app but not
recommended. Remember, this approach should make your life easier.

We can split the apps by domain, feature, page, and section.

There are two frameworks currently which implement this architecture:

single-spa and frint.js.

You don’t need frameworks to implement but, using one of these makes
your transition from monolith to micro frontends easier.

Don’t use it for small apps.

. . .
 Conclusion
I know Microfrontends is such a trendy thing but you should not use it for
every app. Do not use it if your app is small and don’t complicate it. This
approach should make our whole process seamless not over complicated.
So use your best judgment before using this approach.

Sign up for BB Tutorials & Thoughts

By Bachina Labs

Tutorials Ranging from Beginner guides to advanced on Frontend, Backend, Blockchain,

Docker, k8s, DevOps, Cloud,AI, ML. Thank you for subscribing and let me know if you
want me cover anything? Take a look

Your email Get this newsletter

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more
information about our privacy practices.

JavaScript Angular Web Development Programming Software Development

Discover Medium Make Medium yours Become a member

Welcome to a place where words matter. On Follow all the topics you care about, and we’ll Get unlimited access to the best stories on
Medium, smart voices and original ideas take deliver the best stories for you to your Medium — and support writers while you’re at
center stage - with no ads in sight. Watch homepage and inbox. Explore it. Just $5/month. Upgrade

About Help Legal