"Micro-frontends from A to Z. How and Why we use Micro-frontends in Namecheap", Artem Zakharchenko

Biography
· Gameloft
· DevPro
· Pics.io
· Epam
· Namecheap.com
· Frontend
· Backend
· Infrastructure
· Pre-sale
· System Design
Founder Stellar Ukraine
Charity Foundation
Founder KharkivJS
Conference

The story starts with a
reference to the past.

Which reasons to use
Microservice?
2014

· Increase Resilience
· Improved scalability
· The ability to use the right tool for the right task
· Fast and ﬂexible delivery
· Easier debugging and maintenance
· Improved ROI with reduced TCO
· Mitigate Convey Law Risk
Reasons to use Microservices

Microservices is not a
silver bullet
2017–2018

What about Frontend
Microservices?
2018

2015 – We have started migrating our monolith to microservices.
2016 – Monolith becomes smaller. Microservices grow. Frontend
remains unchanged.
2017 – Monolith becomes smaller and smaller. Microservices are
everywhere. Frontend remains unchanged.
2018 – What to do with frontend?
History

How usually Frontend looks
like in huge projects
Service [1]
Service [2]
Service [3]
Frontend
Gateway

Let’s see in more detail…
Frontend

What we really had?
· CMS served tones Frontend pages
· Some separate FE services on NodeJS
· No rules
· No agreement
· 16 Lighthouse Desktop Score
· Dozens of unknown scripts loading
· Multiple version of same dependencies

Service [1]
Service [2]
Service [3]
Frontend
Gateway Backend for
Frontend [1]
Backend for
Frontend [2]
Our next step is frontend
extraction

Beneﬁts
· Independent deploys
· Frontend agnostic approach
· Developers can use modern technology
· Development Experience
· Faster changes

Enough? Almost…
· What about structural consistency?
· What about UI consistency?
· What about cross dependent releases?
· What about sharing UI functionality?
· What about reusing part of UI on different pages?

So we decided to try
frontend microservices…

Goals
· Page consists of several fragments
· Fragment is independent application
· Application supports client side routing
· SSR should be supported
· UI have to be consistent

Requirements
· HTML Page is delivered by layout streaming system
· A unit of streaming is a fragment
· Streaming is lighting fase
· Fragment is a regular frontend application
· Framework Agnostic
· CSS Isolated
· Support Global Routes
· Fragment Delivery is Independent
· Fragment knows nothing about others
· Code sharing

Organizational goals
· Mitigate Convey Law Risks
· Team is independent unit
· Application and system should be testable and reliable
· Avoid communication overkill

Application #1
Application #2
Application #3
Imagine it is your browser

New Architecture
Service [1]
Service [2]
Service [3]
Gateway
Frontend
Microservice
Engine
Fragment [1]
Fragment [2]
Fragment [3]

But in reality…
Service [1]
Service [2]
Service [3]
Gateway
Frontend
Microservice
Engine
Fragment [1]
Fragment [2]
Fragment [3]
Scary Part of
Frontend

Full Architecture View
Service [1]
Service [2]
Service [3]
Gateway
Frontend
Microservice
Engine
Fragment [1]
Fragment [2]
Fragment [3]
Frontend
Microservice
Registry
App #1
App #2
App #3

What is Microservice Engine?
Web Service responsible for processing
incoming requests, discover page
fragments, communicate to fragment
services and form HTML.

What is Microservice Registry?
Web Service with persistent storage that
manage basic entities like routes,
template, fragments and their relationship.

What is Fragment?
Development unit. It is just regular
frontend service.

How it works together. Server Side
Browser Gateway
Frontend
Microservice
Engine
Frontend
Microservice
Registry
Fragments
Form HTTP
Response
HTML Inject Scripts
Inject JSON
conﬁguration
Object

How it works together. Client Side
Browser
Load
Microservice
Engine Script
Load Injected
Fragment
Scripts
Parse
Conﬁguration
Object
Match Route
Load ESM
Modules for
Fragments
Render/Hydrate
Applications

Client/Server side routing
Allow to build isomorphic routing.
Browser
Frontend
Microservice
Engine
Router
App Router [1]
App Router [2]
App Router [3]

Client side routing. Frontend
Browser MSS Engine App Routes
route/ms1
route/ms2
route/ms3
route/*
/ms1
/ms2
/ms3

What is Template ?
</head>
<body>
<ilc-slot id="navbar" />
<ilc-slot id="body" />
<ilc-slot id="footer" />
</body>
</html>

Template customization
</head>
<body>
<header> Hello World!!! </header>
</body>
</html>

What is Route
Route Template
Slots

• Anchor for a Frontend Application.
• Declare node from Application is embedded.
What is Slot

What is Route
Route Template
Slots Application

Client Side Integration
const application = {
bootstrap: () => Promise.resolve(),
mount: () => Promise.resolve(),
unmount: () => Promise.resolve(),
}

Bootstrap
This lifecycle function will be called once, right before the
registered application is mounted for the ﬁrst time.

Mount
mount = async (props: LifecycleFnProps): Promise<Root> => {
const slotNode = props.domElementGetter();
const root = createRoot(slotNode);
root.render(<div>Hello World</div>);
return Promise.resolve(root);
};
This lifecycle function will be called whenever the registered
application is not mounted, but it is ready to be. This function
should create DOM elements, DOM event listeners, etc. to
render content to the user.

Unmount
This lifecycle function will be called whenever the registered
application is mounted. When called, this function should
clean up all DOM elements, DOM event listeners, leaked
memory, globals, observable subscriptions, etc.
unmount = async () => {
const reactRoot = this.getRoot();
if (reactRoot) {
reactRoot.unmount();
}
};

Server Side Integration
With every request for SSR content from the app ILC sends the
following meta-information as query params:
• Router Properties
• BasePath
• RequestURL
• Application Properties
• Header x-request-uri. Request URL string. This contains only
the URL that is present in the actual HTTP request.

Server Side Integration
SSR response has to contain:
• Body with HTML
• Header Link
• Header x-head-title
• Header x-head-meta

processResponse(response, {
pageTitle: meta?.title,
pageMetaTags: `${meta?.meta || ''}${meta?.link || ''}`,
appAssets: await this.applicationManifestConfig.getAppAssets(),
});
response.send(html);
Code example

The goal is to not
affect it at all.

Really. Development is
almost not affected.
Almost…

Over complication is
only integration.

Developers still can…
• Choose JS Framework
• Choose CSS Framework
• Decide if SSR is Required
• Control their build process
• Control their deploy

SO what do we have…
Application #1
Application #2
Application #3
• MS engine allows to build pages by
fragments.
• Fragment is independent App.
• Fragment can be deploy and change part
of the page.
• Your app can support client side
navigation.
• SSR is supported.

This is the culmination
but not the end.

How to Conﬁgure It?
Admin Panel.

How to Conﬁgure It?
Conﬁguration as a Code.

Do you remember this slide?
Browser
Frontend
Microservice
Engine
Router
App Router [1]
App Router [2]
App Router [3]
*It is not 100% truth. I will explain later.

To be more precise this string…
Browser
Frontend
Microservice
Engine
Router
App Router [1]
App Router [2]
App Router [3]
*It is not 100% truth. I will explain later.

Soft navigation
Hard navigation
Router [1]
Router [2]
Router [3]
Router [A]
Router [B]
Router [B]
Router. Template Mismatch.

It is ﬁne when everything’s ﬁne 😌
Application #1
Application #2
Application #3

Application #1
Application #2
Application #3
But what if not everything is ﬁne? 🤨

Application #1
Application #2
Application #3
What if it is a disaster?!! 😩

What are the reasons for this?
• Client Side Runtime Error
• Server Side Error
• Client resources are not available
• Server is not available

• Customer should not suffer.
• One Application with Error has not to break page.
• Business and Development can deﬁne own fault tolerance strategy.
How to react on Errors and Outage?

Fragment types
• Primary
• Essential
• Regular

• SSR: all 5xx response codes trigger the 500 error page
conﬁgured in ILC.
• CSR: any error caught by ILC errorHander, or errors during
loading/mounting trigger the 500 error page conﬁgured in ILC.
Primary Application Type

• SSR: all non-2xx response codes are treated as SSR error and
the second rendering attempt will be done on the client-side.
loading/mounting trigger the 500 error page conﬁgured in ILC.
Essential Application Type

• SSR: all non-2xx response codes are treated as SSR error and
the second rendering attempt will be done on the client-side.
loading/mounting are logged without any further action.
Regular Application Type

Developers manage how
your app reacts on error

What is 500 error page in
term of microservices?

What is an Error Page?
• Works similar to regular route
• Associated with template
• Could be associated with apps but here developer should be
carefully because all your backend can be not accessible.

• Route does not exists on MS Engine level
• Route does not exists on Service level
• Entity does not exists on Service level
Error 404

Error 404
● Route does not exists on MS Engine level
○ System renders global 404
● Route does not exists on Service level
○ Developer can decide to show own 404 or global
● Entity does not exists on Service level
○ Developer can decide to show own 404 or global
Consider that global 404 page is a regular and can handle majority of cases you have

Customise Page Transition UI
● MS Engine can handle re-rendering of apps on the page
● API for customising loaders

Page Transition Hooks
● Stop navigation and use your custom behavior such as
authentication form as an example to navigate whenever you need
(CSR).
● Redirect to a new location (CSR, SSR).
● Continue navigation (CSR, SSR).

Plugin Types
● Page Transition Plugins
● Reporting Plugins
● Localisation Plugin

Shared Library
● Client side modules designed to share between pages
● Deliver without server side only client bundle
● Consumer receive updates right after deploy

Using Shared Fragments
● Ensure polyﬁll loading
● Load Bundle With Common deps
○ React
○ Mobx
○ L10n
○ EventBus

Using Shared Fragments
</head>
<include id="shared" src="https://host-1.server.net” timeout="10000"></include>
<body>
</body>
</html>

Dev Experience
● Developers don’t want to run tons of docker containers
● Developers don’t want to checkout tons of git repo

How to develop
Application #1
Application #2 (Mine)
Application #3

How to develop
Application #1
Application #3
CDN
Remove Server

How to develop
Application #1
Cookie configuration
Application #3
CDN
Remove Server
Local Static
Local Server

Why is it performant
● Horizontal scaling of backend service
● Built-in caches
● Minimum amount of computation
● Client side logic is backend agnostic

Conclusion
● MS increases complexity on your frontend
● MS microservices is not about code splitting
● MS should not effect frontend dev experience
● MS should be fault tolerant
● MS should have robust monitoring system
● Local development should convenient

What ILC Allow
● Deliver part of the page independently
● Isomorphic Client side and Server side navigation
● Support of SSR
● Error Handling System
● Fault Tolerance System
● Solution for Local Development
● Monitoring using plugin system
● Auth Capabilities
● Multi domain support
● Conﬁguration as a Code
● Does not break your regular experience

"Micro-frontends from A to Z. How and Why we use Micro-frontends in Namecheap", Artem Zakharchenko

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to "Micro-frontends from A to Z. How and Why we use Micro-frontends in Namecheap", Artem Zakharchenko

Similar to "Micro-frontends from A to Z. How and Why we use Micro-frontends in Namecheap", Artem Zakharchenko (20)

More from Fwdays

More from Fwdays (20)

Recently uploaded

Recently uploaded (20)

"Micro-frontends from A to Z. How and Why we use Micro-frontends in Namecheap", Artem Zakharchenko