"Micro-frontends: Scalable and Modular Frontend in Parimatch Tech", Kyrylo Aistrakhanov
0 likes420 views
The document discusses the architectural approach of microfrontends, highlighting their benefits such as independent deployments, component-oriented testing, and encapsulation. It emphasizes the need for teams to adapt to a scalable structure that aligns with their communication model while maintaining autonomy in development. Additionally, it outlines technical integration strategies, including module federation and the utilization of web components, to ensure flexibility and performance in a chaotic multi-framework environment.
![Deployments
Team A
Team B
Team C
// Fully Independent
// Load and executes as regular webpack module can be deployed to npm
or as a simple static to server.
// We got a risks to broke something, so we need automatization and
regression.
// We need to keep contracts stable, and use soft deprecation for unused
contracts
Browser NGINX
Infra
cache
CI/CD
assets/styles.[hash].css
assets/bundles.[hash].js
assets/remoteEntry.js
assets/images.png
assets/styles.[hash].css
assets/bundles.[hash].js
assets/remoteEntry.js
assets/images.png
assets/styles.[hash].css
assets/bundles.[hash].js
assets/remoteEntry.js
assets/images.png
CI/CD
CI/CD](https://image.slidesharecdn.com/presentationaistrakhanov-221111174300-02298c03/85/Micro-frontends-Scalable-and-Modular-Frontend-in-Parimatch-Tech-Kyrylo-Aistrakhanov-51-320.jpg)
![Team A
Team B
Team C
Browser NGINX
Infra
cache
CI/CD
CI/CD
CI/CD
Deployments Versioning Possibility
Team A
Team B
Team C
Browser NGINX
Infra
Semantic Release
cache
CI/CD
1.0.1/styles.[hash].css
1.0.1/bundle.[hash].js
1.0.1/remoteEntry.js
1.0.1/styles.[hash].css
1.0.1/bundle.[hash].js
1.0.1/remoteEntry.js
1.0.1/styles.[hash].css
1.0.1/bundle.[hash].js
1.0.1/remoteEntry.js
CI/CD
CI/CD
assets/1.0.1/mfe1
assets/1.0.1/mfe2
assets/1.0.1/mfe3](https://image.slidesharecdn.com/presentationaistrakhanov-221111174300-02298c03/85/Micro-frontends-Scalable-and-Modular-Frontend-in-Parimatch-Tech-Kyrylo-Aistrakhanov-52-320.jpg)
"Micro-frontends: Scalable and Modular Frontend in Parimatch Tech", Kyrylo Aistrakhanov
- 2. Demystifying Is an architectural approach. That comes from the Back-End world and for now adopted for MFE. Monolith SPA SPA Monolith Microservices Microservices Microfronends Front-end Back-end
- 3. Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway’s Law Melvin E. Conway
- 4. It’s all about scaling and adding new teams Team C Team B Team A git git git own environment CAN BE TESTED INDEPENDENTLY INTEGRATION / VISUAL E2E TESTS DEVELOP DEVELOP DEVELOP own environment own environment
- 5. // Independent Releases and Deployments // Automous Development // Model Around Business Domains // Framework Agnostic and Technology Independent // Can be simply deleted or replaced by other component // Can be easily embbeded // Encapsulation
- 6. Benefits of Microfrontends // Sustainability // Fast release cycle, independent deploys // High expertise in domain-based cross-functional teams // Autonomous development // Component-oriented testing
- 7. Maybe you already have a working project? So maybe you will need: // Performance: no overhead in network requests or JS size // No code duplication // Encapsulation level // Iteratively move on new technology, do not stop working business // So depends on previous point it might be easy to embed // Do not lack in development experience // Highly configurable front-end, feature-flags, predicate system, AB testing
- 8. Examples // Authorisation and Registration Widgets Mostly any part of application, or page might be a modularized. Depends on your domains and philosophy of decomposition // Personal user cabinet // Payments Page
- 9. Microfrontends is a subdomain representation on FE // Strict boundaries // Clean and stable contracts // No shared logic with another domains // Independent and release cycles with fault tolerance
- 10. Modules Decomposition Decoupling // Independent/Self-contained (Low Coupling): A module has to be as detached from other dependencies as possible. // Specific (High Cohesion): Elements within one class/module should functionally belong together and do one particular thing. // Reusable: A module has to be easy to integrate into various kinds of programs to perform its task
- 12. And it’s all united in one environment under one resource
- 13. How can we orchestrate it? Build Time (From Different Packages) - not true, you got a single release point Server Side - seems quite good, but you need team with knowledge in at least SSI or some alternative to compose you FE on BE, it may be some additional semi BE framework. Client Side - True way for real frontenders, just joking, we are the engineers and must to know a lot. Incredible scaling. A root application that dynamically loads each independently deployed web application Just a few players: Single SPA, Piral, Mosaic9, ILC, Open Com- ponents, Bit.
- 14. Orchestration Strategies Build Time Integration Browser Server Build&Deploy Repository Server Side Integration Runtime Integration
- 15. Microfrontends Basic Suite Kit // Shell. Routing. Orchestrating. Configurations manifest with list of resources to load // Module. (.render method to embed it somewhere) // Some Way of Communication between them - of course Event Based. Pull Based or Push Based
- 16. Do not couple business subdomains! // Contracts IN // Contracts OUT Just a basics of components Event Bus Lifecycle Hoks Internal State Properties Own Dependencies Shared Dependencies Events Integration Layer Business Domain-related Component
- 17. Modules in Front-End Simple .js scripts and functions (IIFE module pattern) AMD | UMD ES6 Modules Custom modules system (build toolings such as webpack, systemjs with import maps, etc.)
- 18. IIFE - the grandpa of modules Technically you can just create and simple functions with some properties in it, write some CSS, set it as static somewhere on CDN, and add it into your apps. Implement you render or mount method to stick into DOM or attach to something. Handle some properties, bubble some events, profit?
- 19. It’s an old Jquery Plugins. But just imagine that it is more complex app, not a part of UI kit or UI library
- 20. Bundlers, transpilers, frameworks to handle it all, we wrote our routing soluitions. So you will need to create some ".render, .mount” methods, provide wrappers, lifecycle hooks, handle the code duplication by yourself, tracking the versions mismatches, care about islolation and encapsula- tion…
- 21. Approaches that we faced. Runtime integration iFrames Module Federation WebComponents + ES6 modules
- 22. iFrames // First class encapsulation // Own window and globals (DOM) // Easy to embed on page // Can be lazy loaded // Control and restricted over access to internals // Communication through window.postMessage events
- 23. Deployments and Autonomous Development Fully independent deployments Fully framework- agnostic solution
- 24. Drawbacks No code duplication control Got limited view to render
- 26. Federated Modules part // Our case: Monolith with 2y/o react/redux-observables codebase // From 11 to 15-20 teams // From 10 to 100 engineers // Highly configurable product with a lot of dynamics load, AB tests and feature flags
- 28. Module Federation // Provide Loading chunks and webpack modules from different hosts // Natively feels like working with dynamic imports, same API, promises and modules with low-level webpack modules code. // Best fit for teams that develops around webpack, and had similar tech stack around company (Only React/Preact, Angular, Vue etc.). // You need to handle encapsulation by yourself. // Linting and conventions must help
- 30. RemoteEntry - IOC container
- 31. Code Duplication We can share dependencies and we need to mark em as shared in different modules and shell itself
- 32. Default Strategy based on Sem Ver. v1.2 will not be loaded will be loaded v1.5
- 33. Default Strategy based on Sem Ver. L O A D I N G... v2.2 will be loaded will be loaded v1.5
- 34. Additional Possibilities If you are now that no breaking changes provided in versions, you can add it as range '^2.6.5' Will provide an error Will load provided version of package anyway REQUIRED VERSION: VERSION RANGE | FALSE
- 35. Syncronous loading of dependencies EAGER: TRUE
- 36. Our solution with shell // Application startup // Shared dependency’s provider // Routing // Initialise Event Bus // Hosts internal SDK’s // Soft deprecation of unused API’s Shared dep. Shared dep. Shared dep. SHELL Routing Initialisation Orchestration Basic Configs Shared dep. remoteApp remoteApp remoteApp remoteApp remoteApp
- 37. Dynamic Modules loading on demand
- 38. Dynamically Load RemoteEntry Container
- 39. Wrapper around webpack internals
- 40. Simply lazy-load component. Incredible flexibility
- 41. Fault tolerance and no CLS with skeletons A CHAIN IS AS STRONG AS THE WEAKEST LINK
- 42. Scope - meta information for your crashlytic
- 43. Style Isolation CSS-in-js with custom hash settings in each MFE for more unique names Or conventions ( But we cannot rely on conventions in multiple teams)
- 44. Cross-component communication Because Module Federation works similar to your own SPA solution without ecnapsulation you should use your approach. We use an Push-Based RX-bus based EE. Event-based module is perfect fit for the low-coupled systems. Event Bus Lifecycle Hoks Internal State Properties Own Dependencies Shared Dependencies Events Integration Layer Business Domain-related Component
- 45. Why rxjs? Data provider Observable Consumer Consumer Consumer Flow of events. Push-Based approach. RxJS is a library for composing asynchronous and event-based programs by using observable sequences. It provides one core type, the Observable, satellite types (Observer, Schedulers, Subjects) and operators inspired by Array methods (map, filter, reduce, every, etc) to allow handling asynchronous events as collections
- 46. After subscription Consumer Will Get Next Value 1 2 3 4 4 Observe Consumer
- 47. Behavior SIMPLY STORES THE CURRENT VALUE 1 2 3 3 4 4 Observe Consumer
- 48. Scoped namings will create Behaviour Subject
- 49. Event Bus is just an abstraction By the way we try to scope our messages around business domains and subdomains: // user.data.updated // user.data.received // sports.tournaments.updated Event Bus Lifecycle Hoks Internal State Properties Own Dependencies Shared Dependencies Events Integration Layer Business Domain-related Component
- 50. Tooling and contracts control Events Schema ESlint Plugin MFE1 ESlint Plugin MFE1
- 51. Deployments Team A Team B Team C // Fully Independent // Load and executes as regular webpack module can be deployed to npm or as a simple static to server. // We got a risks to broke something, so we need automatization and regression. // We need to keep contracts stable, and use soft deprecation for unused contracts Browser NGINX Infra cache CI/CD assets/styles.[hash].css assets/bundles.[hash].js assets/remoteEntry.js assets/images.png assets/styles.[hash].css assets/bundles.[hash].js assets/remoteEntry.js assets/images.png assets/styles.[hash].css assets/bundles.[hash].js assets/remoteEntry.js assets/images.png CI/CD CI/CD
- 52. Team A Team B Team C Browser NGINX Infra cache CI/CD CI/CD CI/CD Deployments Versioning Possibility Team A Team B Team C Browser NGINX Infra Semantic Release cache CI/CD 1.0.1/styles.[hash].css 1.0.1/bundle.[hash].js 1.0.1/remoteEntry.js 1.0.1/styles.[hash].css 1.0.1/bundle.[hash].js 1.0.1/remoteEntry.js 1.0.1/styles.[hash].css 1.0.1/bundle.[hash].js 1.0.1/remoteEntry.js CI/CD CI/CD assets/1.0.1/mfe1 assets/1.0.1/mfe2 assets/1.0.1/mfe3
- 53. You can dynamically wrote remotes path’s Dynamic Loading provides us possibillity to generate path’s on the fly. So just load your Dependency Containers from ‘https://your-domain.com/v.0.1.1/remoteEntry.js’
- 54. Configurabillity Because we got fully runtime-based composition, we can rely on remote-configs or manifests to configure our app without rebuilding or re-deploying it. We can literally hide everything under the feature flags or AB tests in runtime Product Manager Configs Provider Slider Footer Consumer Off On
- 55. Testing Micro frontends are about automatisation. Unit -> Component Testing -> Integration tests We might test it on it own environment, then on top of it - integration +End-2-End tests
- 56. Performance budgeting Provide a performance budgets as soon as possible, to prevent your colleagues bundle 2mb of icons in their MFE and impacts Web Vitals // Sitespeed + Grafana // Webpagetest + Grafana // LightHouse CI // Webpack Bundlesize
- 57. Cashing Strategy // Hashes for vendors and bundles // Infrastructure cache-control (СloudFlare or similar) // ServiceWorker-based cache for static // eTags // SDK-level caching // Transport-layer caching and butching in workers
- 58. Amount Of Requests in isolated modules might be trouble Highly independent modules Impacts Infra and Browser Performance with their requests. We implemented and SDK’s with their own level of caching and provide to reuse it. Service Workers and Dynamic Modules Loading on demand - is key.
- 59. Frankenstein: Different Frameworks on Page // Legacy solutions // Moving to the new technologies // Any other root cause… But keep in mind that current frameworks doesn’t share common environment nicely (Routing, globals, etc.). Module Federation: No framework agnostic approach out of the box. But we can still do this. You will need some wrappers.
- 60. Conclusions about Module Federation // Good for teams that already on webpack. // Provides you posibility to split release cycles and make them faster. // Shared dependency and their control are so useful // Not very high level of encapsulation and isolation out of box, but you can handle it with conventions and toolings. // Onboarding of newcomers is easy. // Need some additional work to create a frankenstein (multiple frameworks on same page). // Embeddable in the webpack applications.
- 61. For everything else, there's Webcomponents and ES6 modules // It’s close to standarts // High level of encapsulation (DOM, Styles) // Shadow DOM and Custom Elements API // Framework agnostic // Easy to embed, works in any WEB context // And you can combine it with Module Federation
- 62. WebComponents Suite ES6 modules Custom Elements Shadow DOM HTML templates DOCUMENT SHADOW HOST DOCUMENT SHADOW HOST SHADOW TREE SHADOW TREE DOCUMENT TREE FLATTENED TREE (FOR RENDERING) SHADOW ROOT SHADOW HOST
- 63. Frankenstein CookBook // Define Custom Element // Create some div inside WebComponent // On ConnectedCallback() lifecycle hook - just mount your framework-based app to the div. // And you can combine it with Module Federation
- 64. Few words about WebComponents // SSR - main drawback for now // DX - good if you use some microframeworks (Lit/Stencil etc..) // Deployments - easy, static or npm packages. // Encapsulation - Medium. DOM, css. // Easy to embed on page because of Custom Elements (for some frameworks such as react, you still need a wrapper) // Communication - Custom Events. Conclusion: Long-term bet on web standards
- 65. Win // ~15 teams: Freedom for teams and developers // Less cognitive load: Easy to onboard newcomers on project // Domain-based experience focus // Fast Release Cycles: Releases every day, except friday of course // Sustainability: 1.5+ year on production with current approach
- 66. Teams and Front-end Scaling Micro frontends are more likely about the philosophy of finding the perfect balance between technical and communication overhead and stability with excellent development freedom and experience.