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.
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
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
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.
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 🙋♂️
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
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
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>
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
Hinweis der Redaktion
This is a huge topic and today we’ll only go through the most crucial and complex points. Feel free to ask questions about points I haven’t mentioned here.
Hello guys!
Glad to see all of you here in the room. Today we’re gonna be talking about web components.
How many of you are familiar with this technology?
And who actually tried them in production?
Ok, good to see we’re on the same page. For those of you who didn't have a chance to look at the WCs technology there gonna be a quick walkthrough in the next slides.
Why I talk about them. Talk business case. Use requirements prom prev. Presentation. + FOUC
Who haven’t heard?
Talk for two groups:
Never heard
Already familiar
To explain current state of things.
-------------
Plan:
About me
Short intro about WCs
Section: Disclaimer: they’re production ready
Browser support overview & IE/Edge warning
Frameworks overview
Section: But they’re still not perfect (format: issue definition / solution)
CSS loading, FOUC
CSS sharing
SSR
Versioning
Integration with React
CSS: context dependent styles
CSS: styling slotted content
Maybe: create a repo with workaround samples
But first, let me say a few words about myself and the company that supported me in the research work.
Currently I work in R&D team at Namecheap and responsible for acceleration of the innovations within the company.
Generally I’m JS guy who also likes and experienced in DevOps an Software Architecture.
And of course shoot me with email or text me in any messenger if you will have any questions and won’t be able to find me after presentation.
For those who never really heard about NC: it’s a company that has a goal to “open the door for everyone to a free and open Internet”.
We’re doing this by providing people with all they need to get online and standing for the freedom of the Internet.
Mention here how this architecture can be sold to the business.
Need to mention that app should already have SSR
Plus SSR here is optional