{"id":4296,"date":"2020-09-06T23:13:47","date_gmt":"2020-09-06T21:13:47","guid":{"rendered":"https:\/\/angulararchitects.io\/?p=4296"},"modified":"2024-01-19T15:06:16","modified_gmt":"2024-01-19T14:06:16","slug":"dynamic-module-federation-with-angular-2","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/dynamic-module-federation-with-angular-2\/","title":{"rendered":"Building A Plugin-based Workflow Designer With Angular and Module Federation"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 4 of 10 in the series “Module Federation”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. The Microfrontend Revolution: Module Federation in Webpack 5<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. The Microfrontend Revolution: Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. Dynamic Module Federation with Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Building A Plugin-based Workflow Designer With Angular and Module Federation<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  5. Getting Out of Version-Mismatch-Hell with Module Federation<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Using Module Federation with (Nx) Monorepos and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  7. Pitfalls with Module Federation and Angular<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  8. Multi-Framework and -Version Micro Frontends with Module Federation: Your 4 Steps Guide<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  9. Module Federation with Angular’s Standalone Components<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  10. What’s New in our Module Federation Plugin 14.3?<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    In the previous article of this series<\/a>, I showed how to use Dynamic Module Federation. This allows us to load Micro Frontends -- or remotes, which is the more general term in Module Federation -- not known at compile time. We don't even need to know the number of remotes upfront.<\/p>\n

    While the previous article leveraged the router for integrating remotes available, this article shows how to load individual components. The example used for this is a simple plugin-based workflow designer.<\/p>\n

    \"The<\/p>\n

    The workflow designer acts as a so-called host loading tasks from plugins provided as remotes. Thus, they can be compiled and deployed individually. After starting the workflow designer, it gets a configuration describing the available plugins: <\/p>\n

    \"The<\/p>\n

    Please note that these plugins are provided via different origins (http:\/\/localhost:4201<\/a> and http:\/\/localhost:4202<\/a>), and the workflow designer is served from an origin of its own (http:\/\/localhost:4200<\/a>).<\/p>\n

    \ud83d\udcc2 Source Code<\/a><\/p>\n

    \n

    Thanks to Zack Jackson<\/a> and Jack Herrington<\/a>, who helped me to understand the rater new API for Dynamic Module Federation.<\/p>\n<\/blockquote>\n

    Important<\/strong>: This article is written for Angular and Angular CLI 14.x<\/strong> and above. Make sure you have a fitting version if you try out the examples outlined here! For more details on the differences\/ migration to Angular 14.x please see this migration guide<\/a>.<\/p>\n

    Building the Plugins<\/h2>\n

    The plugins are provided via separate Angular applications. For the sake of simplicity, all applications are part of the same monorepo. Their webpack configuration uses Module Federation for exposing the individual plugins as shown in the previous articles of this series:<\/p>\n

    const { shareAll, withModuleFederationPlugin } = require('@angular-architects\/module-federation\/webpack');\n\n module.exports = withModuleFederationPlugin({\n\n   name: 'mfe1',\n\n   exposes: {\n     '.\/Download': '.\/projects\/mfe1\/src\/app\/download.component.ts',\n     '.\/Upload': '.\/projects\/mfe1\/src\/app\/upload.component.ts'\n   },\n\n   shared: {\n     ...shareAll({ singleton: true, strictVersion: true, requiredVersion: 'auto' }),\n   },\n\n });<\/code><\/pre>\n
    One difference to the configurations shown in the previous articles is that here we are directly exposing standalone components. Each component represents a task that can be put into the workflow.   <\/p>\n
    The combination of singleton: true<\/code> and strictVersion: true<\/code> makes webpack emit a runtime error when the shell and the micro frontend(s) need different incompatible versions (e. g. two different major versions). If we skipped strictVersion<\/code> or set it to false<\/code>, webpack would only emit a warning at runtime.<\/p>\n
    Loading the Plugins into the Workflow Designer<\/h2>\n
    For loading the plugins into the workflow designer, I'm using the helper function loadRemoteModule<\/code> provided by the @angular-architects\/module-federation plugin. To load the above mentioned Download<\/code> task, loadRemoteModule<\/code> can be called this way:<\/p>\n
    import { loadRemoteModule } from '@angular-architects\/module-federation';\n\n [...]\n\n const component = await loadRemoteModule({\n     type: 'module',\n     remoteEntry: 'http:\/\/localhost:4201\/remoteEntry.js',\n     exposedModule: '.\/Download'\n })<\/code><\/pre>\n
    Providing Metadata on the Plugins<\/h2>\n
    At runtime, we need to provide the workflow designer with key data about the plugins. The type used for this is called PluginOptions<\/code> and extends the LoadRemoteModuleOptions<\/code> shown in the previous section by a displayName<\/code> and a componentName<\/code>:<\/p>\n
    export type PluginOptions = LoadRemoteModuleOptions & {\n     displayName: string;\n     componentName: string;\n };<\/code><\/pre>\n
    \n
    An alternative to this is extending the Module Federation Manifest as shown in the previous article on Dynamic Module Federation<\/a>.<\/p>\n<\/blockquote>\n
    While the displayName<\/code> is the name presented to the user, the componentName<\/code> refers to the TypeScript class representing the Angular component in question.<\/p>\n
    For loading this key data, the workflow designer leverages a LookupService<\/code>:<\/p>\n
    @Injectable({ providedIn: 'root' })\n export class LookupService {\n     lookup(): Promise<PluginOptions[]> {\n         return Promise.resolve([\n             {\n                 type: 'module',\n                 remoteEntry: 'http:\/\/localhost:4201\/remoteEntry.js',\n                 exposedModule: '.\/Download',\n\n                 displayName: 'Download',\n                 componentName: 'DownloadComponent'\n             },\n             [...]\n         ] as PluginOptions[]);\n     }\n }<\/code><\/pre>\n
    For the sake of simplicity, the LookupService<\/code> provides some hardcoded entries. In the real world, it would very likely request this data from a respective HTTP endpoint.<\/p>\n
    Dynamically Creating the Plugin Component<\/h2>\n
    The workflow designer represents the plugins with a PluginProxyComponent<\/code>. It takes a PluginOptions<\/code> object via an input, loads the described plugin via Dynamic Module Federation and displays the plugin's component within a placeholder:<\/p>\n
    @Component({\n     standalone: true,\n     selector: 'plugin-proxy',\n     template: `\n         <ng-container #placeHolder><\/ng-container>\n     `\n })\n export class PluginProxyComponent implements OnChanges {\n     @ViewChild('placeHolder', { read: ViewContainerRef, static: true })\n     viewContainer: ViewContainerRef;\n\n     constructor() { }\n\n     @Input() options: PluginOptions;\n\n     async ngOnChanges() {\n         this.viewContainer.clear();\n\n         const Component = await loadRemoteModule(this.options)\n             .then(m => m[this.options.componentName]);\n\n         this.viewContainer.createComponent(Component);\n     }\n }<\/code><\/pre>\n
    In versions before Angular 13, we needed to use a ComponentFactoryResolver to get the loaded component's factory:<\/p>\n
    \/\/ Before Angular 13, we needed to retrieve a ComponentFactory\n \/\/\n \/\/ export class PluginProxyComponent implements OnChanges {\n \/\/     @ViewChild('placeHolder', { read: ViewContainerRef, static: true })\n \/\/     viewContainer: ViewContainerRef;\n\n \/\/     constructor(\n \/\/       private injector: Injector,\n \/\/       private cfr: ComponentFactoryResolver) { }\n\n \/\/     @Input() options: PluginOptions;\n\n \/\/     async ngOnChanges() {\n \/\/         this.viewContainer.clear();\n\n \/\/         const component = await loadRemoteModule(this.options)\n \/\/             .then(m => m[this.options.componentName]);\n\n \/\/         const factory = this.cfr.resolveComponentFactory(component);\n\n \/\/         this.viewContainer.createComponent(factory, null, this.injector);\n \/\/     }\n \/\/ }<\/code><\/pre>\n
    Wiring Up Everything<\/h2>\n
    Now, it's time to wire up the parts mentioned above. For this, the workflow designer's AppComponent<\/code> gets a plugins<\/code> and a workflow<\/code> array. The first one represents the PluginOptions<\/code> of the available plugins and thus all available tasks while the second one describes the PluginOptions<\/code> of the selected tasks in the configured sequence:<\/p>\n
    @Component({ [...] })\n export class AppComponent implements OnInit {\n\n   plugins: PluginOptions[] = [];\n   workflow: PluginOptions[] = [];\n   showConfig = false;\n\n   constructor(\n     private lookupService: LookupService) {\n   }\n\n   async ngOnInit(): Promise<void> {\n     this.plugins = await this.lookupService.lookup();\n   }\n\n   add(plugin: PluginOptions): void {\n     this.workflow.push(plugin);\n   }\n\n   toggle(): void {\n     this.showConfig = !this.showConfig;\n   }\n }<\/code><\/pre>\n
    The AppComponent<\/code> uses the injected LookupService<\/code> for populating its plugins<\/code> array. When a plugin is added to the workflow, the add<\/code> method puts its PluginOptions<\/code> object into the workflow array.<\/p>\n
    For displaying the workflow, the designer just iterates all items in the workflow array and creates a plugin-proxy<\/code> for them:<\/p>\n
    <ng-container *ngFor="let p of workflow; let last = last">\n     <plugin-proxy [options]="p"><\/plugin-proxy>\n     <i *ngIf="!last" class="arrow right" style=""><\/i>\n <\/ng-container> <\/code><\/pre>\n
    As discussed above, the proxy loads the plugin (at least, if it isn't already loaded) and displays it.<\/p>\n
    Also, for rendering the toolbox displayed on the left, it goes through all entries in the plugins<\/code> array. For each of them it displays a hyperlink calling bound to the add<\/code> method:<\/p>\n
    <div class="vertical-menu">\n     <a href="#" class="active">Tasks<\/a>\n     <a *ngFor="let p of plugins" (click)="add(p)">Add {{p.displayName}}<\/a>\n <\/div><\/code><\/pre>\n
    Conclusion<\/h2>\n
    While Module Federation comes in handy for implementing Micro Frontends, it can also be used for setting up plugin architectures. This allows us to extend an existing solution by 3rd parties. It also seems to be a good fit for SaaS applications, which needs to be adapted to different customers' needs.  <\/p>\n
    What's next? More on Architecture!<\/h2>\n
    So far, we've seen that Module Federation is a straightforward solution for creating Micro Frontends on top of Angular. However, when dealing with it, several additional questions come in mind:<\/p>\n