Rustam Aliyev and Ivan Martynov - From monolith web app to micro-frontends – How we extended microservices architecture to frontend
0 likes•323 views
From monolith SPA to micro-frontends describes how a large monolithic single-page application was decomposed into smaller independent micro-frontends or modules. This was done by refactoring the codebase into a monorepo structure managed by Lerna and introducing a thin shared runtime for dependency injection. This allowed each module to be developed and deployed independently while reusing shared components. The new architecture improved ownership, dependency management, deployment, A/B testing and addressed issues with the monolithic structure. Future work may involve using Web Components for communication and alternative tools like Bolt.
![Lerna
• Tool for managing monorepo
• Inter-dependency management
• Publishing
• Testing
• CLI: bootstrap, publish, etc.
• yarn optimised
/* lerna.json */
{
"lerna": "2.5.1",
"npmClient": "yarn",
"useWorkspaces": true, // yarn workspaces
"version": "independent"
}
/* package.json */
{
// yarn workspaces configuration
"workspaces": [
"packages/*"
],
"private": true
}](https://image.slidesharecdn.com/dippevvtkoraanfwj3xm-signature-fcd92262d471534d86692e59df41353f42bb8d7f9dc60d4de9a8edf081f23608-poli-180718193556/85/Rustam-Aliyev-and-Ivan-Martynov-From-monolith-web-app-to-micro-frontends-How-we-extended-microservices-architecture-to-frontend-20-320.jpg)
Rustam Aliyev and Ivan Martynov - From monolith web app to micro-frontends – How we extended microservices architecture to frontend
- 1. From monolith SPA to micro-frontends How we extended microservices architecture to frontend Rustam Aliyev @rstml Ivan Martynov @j_martyn 07/07/2018 OneDome
- 2. What is ”microservice”? • Architectural pattern • Collection of loosely coupled services
- 5. Conway’s Law Produced system design copies organisational structure M. Conway, 1967
- 6. Frontend (SPA) API Gateway (REST, GraphQL) Backend Database Microservice A Team A Backend Database Microservice B Team B Backend Database Microservice N Team N …
- 7. Problems of monolith SPA • Ownership ! • Dependency management " • Shared components # • Deployment and releases $ • A/B testing %
- 8. … Backend Database Microservice A Team A Frontend Backend Database Microservice B Team B Frontend Backend Database Microservice N Team N Frontend… API Gateway (REST, GraphQL)
- 10. Typical SPA Anatomy • One entry point (index.js) • SPA framework • All components in one bundle ... <script src="https://unpkg.com/react/dist/react.js"></script> <script src="/index.js"></script> ...
- 11. Complex monolith SPA • All-in-one SPA bundle • Package per product with custom routings • Shared components in separate packages index.js …App A Package App B Package App N Package Shared Components Package(s)
- 12. Ways to decompose monolith frontend 1. Strong isolation Web Components / IFrame Multiple SPAs / frameworks Communication channels 2. Weak isolation Dependency Injection Single SPA / framework Shared state store
- 13. … App A Package Team A App B Package Team B App N Package Team N Browser Runtime Dependency Injection Shared Components Package ver.A Shared Components Package ver.B Shared Components Package ver.N Thin SPA (injector) Shared Store (Redux, MobX)
- 14. /* app/package.json */ { "dependencies" : { "dependency" : "1.0.0" } } /* app.js */ import dependency from 'dependency'; ... dependency.use(); /* index.html */ <script src="/dependency.v1.0.0.js"></script> <script src="/app.v2.0.0.js"></script> <script src="/thin-spa.js"></script> /* app.js */ export default (dependency) => { dependency.use(); } /* thin-spa.js (injector) */ import app from 'app'; import dependency from 'dependency'; ... app(dependency); // wiring Importing vs Dependency Injection
- 16. Before: project structure Package Thin SPA Package App A Package App B Package Shared Component … Package App N
- 17. Before: Local development workflow 1. Manual symlink or npm link to test 2. Publish components to NPM 3. Deploy whole app cd ~/components npm link cd ~/application npm link components
- 18. Monorepo • A single repository holding the code of many packages • Monorepo ≠ monolith Thin SPA Package App A Package App B Package Shared Components Package … App N Package Monorepo Shared Components Package
- 19. Lerna • Tool for managing monorepo • Inter-dependency management • Publishing • Testing • CLI: bootstrap, publish, etc. • yarn optimised lerna-repo ├─ package.json ├─ lerna.json └─ packages ├─ main-spa │ └─ package.json ├─ design-lib │ └─ package.json ├─ app-a │ └─ package.json └─ app-b ├─ package.json └─ node_modules ├─ design-lib -> ../../design-lib ├─ ...
- 20. Lerna • Tool for managing monorepo • Inter-dependency management • Publishing • Testing • CLI: bootstrap, publish, etc. • yarn optimised /* lerna.json */ { "lerna": "2.5.1", "npmClient": "yarn", "useWorkspaces": true, // yarn workspaces "version": "independent" } /* package.json */ { // yarn workspaces configuration "workspaces": [ "packages/*" ], "private": true }
- 21. Lerna: Local development workflow • Automatically interlinking • Inter-dependencies and downstream versions • Automated testing lerna bootstrap # All packages are symlinked now git commit -a -m "Many changes" lerna publish # Changes: # - app-A: 1.0.1 => 1.0.2 # - app-B: 1.2.1 => 1.3.0 # - utils: 1.5.4 => 1.5.5 # - components: 3.0.4 => 3.0.5
- 22. Deployment
- 23. A … B N … A … B1 N B2 Monorepo (e.g. Git) Web Server Build, test, deployApplications Shared components Micro-frontends Thin SPA
- 24. Results Same bundle size Migrated gradually in background ~1 month
- 25. Summary Before After Ownership ! " Dependency management # $ Shared components % & Deployment and releases ' ( A/B testing ) *
- 26. Future work • Applying Web Components • Communication between modules via event bus • Bolt as an alternative to Lerna • Hierarchical dependency injection
- 27. Questions?