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

2.
Social Media

3.
Let me tell you a story…

4.
The story starts with a
reference to the past.

5.
Which reasons to use
Microservice?
2014

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

7.
Microservices is not a
silver bullet
2017–2018

8.
What about Frontend
Microservices?
2018

9.
Namecheap
development history

10.
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

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

12.
Let’s see in more detail…
Frontend

13.
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

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

15.
Benefits
· Independent deploys
· Frontend agnostic approach
· Developers can use modern technology
· Development Experience
· Faster changes

16.
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?

17.
So we decided to try
frontend microservices…

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

19.
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

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

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

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

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

24.
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

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

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

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

28.
How it works
together

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

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

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

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

33.
What is Route
Route Template

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

35.
Template customization
</head>
<body>
<header> Hello World!!! </header>
<ilc-slot id="navbar" />
<ilc-slot id="body" />
<ilc-slot id="footer" />
</body>
</html>

36.
What is Route
Route Template
Slots

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

38.
What is Route
Route Template
Slots Application

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

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

41.
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.

42.
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();
}
};

43.
That is it!

44.
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.

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

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

47.
How it affects
development?

48.
The goal is to not
affect it at all.

49.
Really. Development is
almost not affected.
Almost…

50.
Over complication is
only integration.

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

52.
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.

53.
This is the culmination
but not the end.

54.
How to Configure It

55.
How to Configure It?
Admin Panel.

56.
How to Configure It?
Configuration as a Code.

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

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

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

60.
What about
reliability?

61.
It is fine when everything’s fine 😌
Application #1
Application #2
Application #3

62.
Application #1
Application #2
Application #3
But what if not everything is fine? 🤨

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

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

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

66.
Fragment types
• Primary
• Essential
• Regular

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

68.
• SSR: all non-2xx response codes are treated as SSR error and
the second rendering attempt will be done on the client-side.
• CSR: any error caught by ILC errorHander, or errors during
loading/mounting trigger the 500 error page configured in ILC.
Essential Application Type

69.
• SSR: all non-2xx response codes are treated as SSR error and
the second rendering attempt will be done on the client-side.
• CSR: any error caught by ILC errorHander, or errors during
loading/mounting are logged without any further action.
Regular Application Type

70.
Developers manage how
your app reacts on error

71.
What is 500 error page in
term of microservices?

72.
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.

73.
What about
other errors?

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

75.
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

76.
Page Transition Handling

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

78.
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).

79.
Plugin System

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

81.
Code Sharing

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

83.
Using Shared Fragments
● Ensure polyfill loading
● Load Bundle With Common deps
○ React
○ Mobx
○ L10n
○ EventBus

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

85.
Local Development

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

87.
Developer wants

88.
npm start

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

90.
How to develop
Application #1
Application #2 (Mine)
Application #3
CDN
Remove Server

91.
How to develop
Application #1
Application #2 (Mine)
Cookie configuration
Application #3
CDN
Remove Server
Local Static
Local Server

92.
Performance

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

94.
Delivery CI/CD

95.
Multi Domain Support

96.
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

97.
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
● Configuration as a Code
● Does not break your regular experience

98.
Social Media

99.
Internal Links

100.
Inspiration Links