Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JS Fest 2019/Autumn. Влад Федосов. Technology agnostic microservices at SPA frontend

31 views

Published on

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.

Published in: Education
  • Create Your Own Odds Playing The Lottery ●●● https://tinyurl.com/t2onem4
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

JS Fest 2019/Autumn. Влад Федосов. Technology agnostic microservices at SPA frontend

  1. 1. Technology agnostic microservices at SPA frontend Vladlen Fedosov, Director of R&D @Namecheap, Inc
  2. 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. 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. 4. “Opening the door for everyone to a free and open Internet”
  5. 5. Do we have an issue here? Problem statement...
  6. 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. 7. What are Microservices?
  8. 8. Ok, got it! But what about frontend?
  9. 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. 10. What are Micro Frontends?
  11. 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. 12. What are the options we have?
  13. 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. 14. What is page composition? Fragment 1 Fragment 2 Fragment 3 Layout
  15. 15. What is page composition? Fragment 1 Fragment 2 Fragment 3 First request, composition may happen at server side
  16. 16. What is page re-composition? Different app was loaded State change 2nd request, re- composition at client side
  17. 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. 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. 19. Our solution overview
  20. 20. Core technologies we used
  21. 21. Zalando Tailor
  22. 22. single-spa - JS framework for Micro Frontends
  23. 23. We need to go deeper...
  24. 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. 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. 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. 27. Challenges - Page composition <html> <head> ... </head> <body> <slot name="navbar"></slot> <slot name="body"></slot> <slot name="footer"></slot> </body> </html>
  28. 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. 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. 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. 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>
  32. 32. Few more advanced things...
  33. 33. 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?
  34. 34. 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" } }
  35. 35. 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
  36. 36. 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 });
  37. 37. 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.
  38. 38. Further improvements ● Integration of the Tailor & single-spa under single tool with unified client/server API ● Template transition handling ● Automated tests ● Documentation
  39. 39. 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

×