O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

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

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 40 Anúncio

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

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.

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.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Diapositivos para si (20)

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

Anúncio

Mais de JSFestUA (20)

Mais recentes (20)

Anúncio

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

Notas do Editor

  • 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
  • Addition of the News SSR app to the frontend

×