We'll go through the possible ways to bring technology agnostic microservice architecture to the frontend, review pros/cons of each of them. We also will check the "ultimate solution" that handles microservices with SSR in SPA manner. This talk will be interesting for ones who have multiple teams working on the same frontend application.

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

2. Continue listening or check Instagram? 🤔
● Problem statement. Do we have an issue?
● Options we have to solve it. Pros/Cons
● Working solution overview
● Extra tips & tricks from our experience

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

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

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

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

7. What are Microservices?

8. Ok, got it! But what about frontend?

9. Meet “Micro Frontends”
In short: they are Microservices architecture that was adopted for UI needs
To be more specific:
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.

10. What are Micro Frontends?

11. 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 🙋♂️

12. What are the options we have?

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

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

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

16. What is page re-composition?
Different app
was loaded
State
change
2nd request, re-
composition at
client side

17. 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 ✅ ✅ ✅ ✅

18. Challenges to be solved
● Page composition & re-composition
● Routing & page transition
● Micro Frontends registry
● Dynamic code loading & updating
● SSR support
● Error reporting
● Cross-fragment communication
● Code isolation
● Guardrails

19. Our solution overview

20. Core technologies we used

21. Zalando Tailor

22. single-spa - JS framework for Micro Frontends

23. We need to go deeper...

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

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

26. Challenges - Code Isolation
Simple rules for micro-frontend developers:
● No “window” modification, no global variables
● No DOM modifications 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

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

28. 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" },
}
}
]

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

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

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

33. Few more advanced things...

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

35. Deploy/Rollback - Notification
● Make API call to the Registry after deployment to CDN but before server
update
● Use version discovery mechanism. Example:
○ Keep metadata file 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"
}
}

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

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

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

39. Further improvements
● Integration of the Tailor & single-spa under single tool with unified
client/server API
● Template transition handling
● Automated tests
● Documentation

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