Micro Apps in the Real World Michael Zikes, ANGULARarchitects.io Routing strategies 

Micro Frontends Architecture State Management Responsive Design What this talk is about Angular support Routing 

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) 

What are those Micro Frontends everybody is talking about? ? 

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 

Architecture targets • Independent builds • Independent deployment • Runtime integration • Multiple frontend frameworks/libraries • Different dependency versions • Possible but hard to manage 

Do Micro Apps really help to build professional web applications? ? 

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 

Do leading frameworks like Angular directly support Micro Frontends? ? 

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) 

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 

How do single Micro Apps react to URL changes? ? 

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 

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? 

Possible strategy • Using named RouterOutlets: • Challenges? https://www.angulararchitects.io/shell(flights:search//passengers:edit/8) 

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) 

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 

Do Micro Frontends and global State Management work well together? ? 

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 

Do I need to consider changes related to Responsive Design? ? 

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 

! • 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 

What happens in near future? Tell me more! ? 

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 

[web] ANGULARarchitects.io [email] [email protected] [twitter] Michael Zikes (@MikeZks) Slides Contact and Downloads Public: Frankfurt, Munich, Vienna In-House: everywhere angulararchitects.io/angular-workshops