Micro Apps in the Real World - Routing strategies - Angular Meetup Graz 01/2021

Transcript

1. Micro Apps in the Real World Michael Zikes, ANGULARarchitects.io Routing strategies
2. Micro Frontends Architecture State Management Responsive Design What this talk is about Angular support Routing
3. About Michael • Michael Zikes ANGULARarchitects.io • Trainings and Consultancy • Focus on Angular Public: Frankfurt, Munich, Vienna In-House: everywhere angulararchitects.io/angular-workshops Michael Zikes (@MikeZks)
4. What are those Micro Frontends everybody is talking about? ?
5. Definition of Micro Frontends • Aim to develop self-contained apps or features • Can be composed and interact with each other • Share a consistent user experience • Play together with Micro Services • Lead to independent developer teams
6. Architecture targets • Independent builds • Independent deployment • Runtime integration • Multiple frontend frameworks/libraries • Different dependency versions • Possible but hard to manage
7. Do Micro Apps really help to build professional web applications? ?
8. Micro Apps & professional Architecture? • Help to achieve certain architecture targets • Requires a mature Application Shell environment to work smoothly • Downsides of dynamic runtime integration • Leads to less predictability • Leads to a higher E2E testing effort • Consider alternatives • w/o runtime integration requirement • w/o need for different technologies • use a Build Monolith instead
9. Do leading frameworks like Angular directly support Micro Frontends? ?
10. Angular framework support • Micro Frontends in a Build Monolith • Default strategy in Angular • Everything is known at build time • Micro Frontends with Module Federation • Same version → load Module like with Lazy Loading, but dynamically • Micro Frontends as Web Components • Angular Web Components with @angular/elements • Almost no direct Angular support for Web Component Micro Apps • Custom implementations necessary • Custom builders & single bundle (see ngx-build-plus)
11. Choose the right approach • Build Monolith • Everything known at build time • Same versions • Apps separated with DDD patterns • Module Federation with same dependency versions • Dynamic cross origin integration possible • Different build- & deployment processes, but same versions • Webpack 5 necessary • Module Federation with different dependency versions • Bootstraping different Apps • No shared dependency injection, but shared dependencies possible • Comparable to Web Components and Angular Root Components
12. How do single Micro Apps react to URL changes? ?
13. Routing • Independent versions lead to more than one Angular forRoot-Router • Other frameworks/libraries may change the URL as well • Angular overwrites URLs resp. unknown routes lead to errors • URL overlapping between Micro Apps
14. Targets for a Routing concept • How many apps need to be active in the shell concurrently? • Do Apps have own demand for changing the Route? • Necessary to manage more than one Route? • Deep Linking between Apps resp. Shell & App? • Are Apps allowed to be nested?
15. Possible strategy • Using named RouterOutlets: • Challenges? https://www.angulararchitects.io/shell(flights:search//passengers:edit/8)
16. Routing challenges • Named Outlets Routing config needs to be present • Otherwise, Router error • Angular Router allows named Outlets on different levels • Tricky to implement Deep Linking • History API: pushState not recognized by Angular Router • How to deal with different frameworks/libraries in same window object? https://www.angulararchitects.io/shell(flights:search)/details(passengers:edit/8)
17. Possible solution • Custom implementation necessary to patch the Router • Central definition, that needs to be respected in every Micro App • Router Outlets with “name”-Binding • Router Link that publishes navigation source • Monkey patch pushState to react on URL changes • Filter URL segments to avoid unknown Outlet errors • Convert App internal to Shell compatible URL • Prevent that certain Apps change the URL
18. Do Micro Frontends and global State Management work well together? ?
19. Global State Management • Is standalone operation of the Micro App required? • Can an App Shell environment with central services be expected? • Majority of cases: • Choose a self-contained Micro App with a small, well defined public interface • Exchange state with data bindings, not with dependency injection • Related to Redux State Management • This may lead to more than one Root-Store w/i the same window object • Redux DevTools and @ngrx/store-devtools support more than one store
20. Do I need to consider changes related to Responsive Design? ?
21. Responsive Design • Bootstrap Grid System uses media queries • Does the App Shell control the Micro App size? • How does your Micro App react if the window viewport stays the same, but the space for the Micro App changes? • Consider to use CSS Flexbox or CSS Grid instead
22. ! • Web Components not always best • Plan to develop a mature App Shell • URL changes are critical • Think of Responsive Design • How to integrate & communicate Key takeaways
23. What happens in near future? Tell me more! ?
24. Follow up • Shared dependencies with Webpack Module Federation • https://www.angulararchitects.io/aktuelles/the-microfrontend-revolution-module-federation-in-webpack-5 • NX library brings a lot of useful features • https://nx.dev/angular • UMD bundles will not be relevant anymore • Micro App Platform • Upcoming community project to patch default behavior (Twitter @MikeZks) • Follow the development of @brandontroberts declarative router • https://github.com/brandonroberts/angular-routing
25. [web] ANGULARarchitects.io [email] michael.zikes@intauria.com [twitter] Michael Zikes (@MikeZks) Slides Contact and Downloads Public: Frankfurt, Munich, Vienna In-House: everywhere angulararchitects.io/angular-workshops