JSFest 2019: Technology agnostic microservices at SPA frontend

Technology agnostic
microservices at SPA frontend
Vladlen Fedosov, Director of R&D @Namecheap, Inc

Mmm... Listen talk or check Instagram? 🤔
● What are microservices at Frontend and why you need to be aware?
● Possible approaches overview. Pros/Cons
● Working solution overview
● Extra tips & tricks from our experience

Vlad Fedosov
Director of R&D @Namecheap
TL;DR:
● 10 years in the industry
● Went path from Junior to Architect
● Use JS since Mootools era
● Amateur DevOps evangelist
● AWS ninja
● Believe in self-organized, cross-functional teams

“Opening the door for everyone to
a free and open Internet”

Do we have an issue here?
Problem statement...

What are Microservices?
Microservices - also known as the microservice architecture - is an architectural
style that structures an application as a collection of services that are
● Highly maintainable and testable
● Loosely coupled
● Independently deployable
● Organized around business capabilities
● Owned by a small team

Ok, got it! But what about
frontend?

JSFest 2019: Technology agnostic microservices at SPA frontend

Meet “Micro Frontends”
In short: they are Microservices architecture that was adopted for UI needs
To be more speciﬁc:
Think about web app as a composition of features which are owned by
independent teams. Each team has a distinct area of business or mission it cares
about and specialises in. A team is cross functional and develops its features
end-to-end, from database to user interface.

Do I need Micro Fragments in my project?
No, unless:
● You have several cross-functional teams working on the same frontend app.
And they want:
○ Independent development lifecycle
○ Independent releases
○ Calm sleep at night w/o a chance of their functionality being broken by other team’s release
● You’re working on a huge enterprise app and want to get out of the golden
cage of your outdated framework.
● Bring your own case 🙋‍♂

What is page composition?
Fragment 1
Fragment 2
Fragment 3
Layout

What is page composition?
Fragment 1
Fragment 2
Fragment 3
First request,
composition may
happen at
client/server side

What is page re-composition?
Diﬀerent app
was loaded
State
change
2nd request,
re-composition at
client/server side

Available approaches
1. Support 1 framework, break code onto NPM modules (static/lazy loading)
2. Support multiple frameworks and
a. compose page at server side
b. compose page at client side
c. compose page at server & client side

Available approaches
Approach / Criteria Technology
agnostic
Code isolation SEO/SM-bots
compatible (SSR)
UX Level
1 Framework, NPM
modules
❌ Limited ✅ ✅
X Frameworks,
client side composition
✅ ✅ ❌ Limited
(longer initial load)
X Frameworks,
server side composition
✅ ✅ ✅ Limited (need to reload
page for re-composition)
X Frameworks,
isomorphic composition
✅ ✅ ✅ ✅

Let’s see what we have in
production nowadays

Our next-gen solution overview:
“Isomorphic Layout Composer”

single-spa - JS framework for Micro Frontends

Challenges we faced with
● Page composition & re-composition
● Routing & page transition
● Micro Frontends registry
● Dynamic code loading & updating
● SSR support
● Error reporting
● Cross-fragment communication
● Code isolation
● Guardrails

Overall architecture - System (high level)
Registry
Client Server
Router
Layout composer
(Tailor)
MS 1
MS 2
MS X
UI composition layer
(single-spa)
Template
engine

Overall architecture - Micro Frontend
App
Shared
Code
client.js
mount()
unmount()
server.js
config ←
Business logic
Client side bundle
Server bundle
Assets
Server runner
Server API
CDN

Challenges - Code Isolation
Simple rules for micro-frontend developers:
● No “window” modiﬁcation, no global variables
● No DOM modiﬁcations outside assigned container
● No shared CSS, apps use Scoped CSS only
● No shared state, apps can communicate only via events
Real experience: we banned Angular as it was patching “window” & had issues if
you’re running 2+ Angular apps on the same page

Challenges - Page composition
<html>
<head>
...
</head>
<body>
<slot name="navbar"></slot>
<slot name="body"></slot>
<slot name="footer"></slot>
</body>
</html>

Challenges - Registry
Holds info about:
● Apps
● Routes
● Templates
apps: {
"@portal/news": {
spaBundle: "http://127.0.0.1:3000/dist/single_spa.js",
cssBundle: "http://127.0.0.1:3000/dist/21f11a2afc03af3d62f8.css",
ssr: { // Optional. If omitted - no rendering will be done at the server side
src: "http://localhost:3000/news/?fragment=1",
},
},
},
templates: { master: "master.template.html" },
routes: [ // Express like routes, matched in order of appearance
{
route: "/news/*",
template: "master",
slots: {
navbar: { appName: "@portal/navbar" },
body: { appName: "@portal/news" },
}
}
]

Challenges - Routing & page transition
/news/latest
Global Router: /news/*
App Router: /latest
/latest
Rule: MF App is aware about it’s own routes only.
Implementation: 2-tiered router

Challenges - Routing & page transition
But how app A can perform transition to the view within app B?
It’s simple - use built in capabilities of your framework. Nothing changes.
1. User clicks link
2. App A framework invokes history.pushState()
3. ILC listens for 'hashchange', 'popstate' & “<a>” click events
4. ILC checks if any changes to the set of the apps visible on a page needed
5. ILC performs unmounting of the old apps & mounts new ones

Challenges - Dynamic code loading
Solution of choice: SystemJS , every App should be built as AMD/SystemJS
bundle & registered in the registry.
It will be loaded as soon as it will be requested by the Global Router or as explicit
dependency in code:
● Webpack “externals”
● System.import('react')
<script type="systemjs-importmap">
{
"imports": {
"@portal/news":"http://127.0.0.1:3000/index.js",
"react": "https://cdnjs.cloudflare.com/.../index.js"
}
}
</script>

Deploy/Rollback
We have two challenges here:
● Notify ILC about new versions of our fragments
● Synchronize versions of the code at server (SSR) & client (Browser)
But how can we solve them?

Deploy/Rollback - Notiﬁcation
● Make API call to the Registry after deployment to CDN but before server
update
● Use version discovery mechanism. Example:
○ Keep metadata ﬁle at CDN with disabled HTTP cache & update it after deploy.
{
"spaBundle": "https://my-cdn.com/app-name/main.c02de4198cc732e5797a.js",
"cssBundle": "https://my-cdn.com/app-name/main.c02de4198cc732e5797a.css",
"dependencies": {
"react": "https://my-cdn.com/app-name/react.v16.0.1.js"
}
}

Deploy/Rollback - Synchronize versions
Registry
App 1: v2
ILC
App 1: v2
ILC
App 1: v1
App server
v1
App server
v2
Not all ILC instances are in
sync with Registry
App deployment in progress...
Special response header:
x-bundle-overrides

Error reporting
1. Use framework built-in capabilities, ILC listens at framework error handlers
2. Be prepared for the worst case scenario:
window.addEventListener('error', function(event) {
const moduleInfo = SystemJS.getModuleInfo(event.filename); // <---
if (moduleInfo === null) {
return;
}
event.preventDefault();
console.error( … );
newrelic.noticeError( … ); // Track errors centrally
});

Cross-fragment communication
There are 3 main options:
● Browser events.
● Shared services.
● Shared state. This solution doesn’t impose or restrict shared state between
Micro-Frontends. Bring your own if you need it.

Further improvements
● Integration of the Tailor & single-spa under single tool with uniﬁed
client/server API
● Template transition handling
● LDE improvements for our engineers
● Automated tests
● Documentation, documentation, documentation...
● Built-in monitoring
● Fragment inside fragment (parcels)

Vlad Fedosov
Director of R&D
@Namecheap, Inc
vlad.fedosov@gmail.com
Slides:
Or just scan it:
bit.ly/2BRrn8V
Source
code:
github.com/StyleT/icl

JSFest 2019: Technology agnostic microservices at SPA frontend

More Related Content

What's hot (20)

Similar to JSFest 2019: Technology agnostic microservices at SPA frontend (20)

Recently uploaded (20)

JSFest 2019: Technology agnostic microservices at SPA frontend