
Building A Plugin-based Workflow Designer With Angular and Module Federation (Part IV)
Module Federation allows loading plugins from other origins,
This article is part of a series:
- Part 1: Module Federation in Webpack 5
- Part 2: Module Federation with Angular
- Part 3: Dynamic Module Federation with Angular
- Part 4: Building A Plugin-based Workflow Designer With Angular and Module Federation
- Part 5: Getting Out of Version-Mismatch-Hell with Module Federation
- Part 6: Using Module Federation with Nx Monorepos and Angular
- Part 7: Multi-Framework and -Version Micro Frontends with Module Federation: The Good, the Bad, the Ugly
In the previous article of this series, 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.
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.
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:
Please note that these plugins are provided via different origins (http://localhost:3000 and http://localhost:3001), and the workflow designer is served from an origin of its own (http://localhost:5000).
As always, the source code can be found in my GitHub account.
Thanks to Zack Jackson and Jack Herrington, who helped me to understand the rater new API for Dynamic Module Federation.
Building the Plugins
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:
new ModuleFederationPlugin({
name: "mfe1",
filename: "remoteEntry.js",
exposes: {
'./Download': './projects/mfe1/src/app/download.component.ts',
'./Upload': './projects/mfe1/src/app/upload.component.ts'
},
shared: {
"@angular/core": { singleton: true, strictVersion: true },
"@angular/common": { singleton: true, strictVersion: true },
"@angular/router": { singleton: true, strictVersion: true }
}
}),
As also discussed in the previous articles, this configuration assigns the (container) name mfe1
to the remote. It shares the libraries @angular/core
, @angular/common
, and @angular/router
with both, the host (=the workflow designer) and the remotes.
The combination of singleton: true
and strictVersion: true
makes webpack emit a runtime error when the shell and the micro frontend(s) need different incompetible versions (e. g. two different major versions). If we skipped strictVersion
or set it to false
, webpack would only emit a warning at runtime.
Besides, it exposes a remote entry point remoteEntry.js
which provides the host with the necessary key data for loading the remote.
Loading the Plugins into the Workflow Designer
For loading the plugins into the workflow designer, I'm using the helper function loadRemoteModule
provided by the @angular-architects/module-federation
plugin. To load the above mentioned Download
task, loadRemoteModule
can be called this way:
import { loadRemoteModule } from '@angular-architects/module-federation';
[...]
const component = await loadRemoteModule({
remoteEntry: 'http://localhost:3000/remoteEntry.js',
remoteName: 'mfe1',
exposedModule: './Download'
})
Providing Metadata on the Plugins
At runtime, we need to provide the workflow designer with key data about the plugins. The type used for this is called PluginOptions
and extends the LoadRemoteModuleOptions
shown in the previous section by a displayName
and a componentName
:
export type PluginOptions = LoadRemoteModuleOptions & {
displayName: string;
componentName: string;
};
While the displayName
is the name presented to the user, the componentName
refers to the TypeScript class representing the Angular component in question.
For loading this key data, the workflow designer leverages a LookupService
:
@Injectable({ providedIn: 'root' })
export class LookupService {
lookup(): Promise<PluginOptions[]> {
return Promise.resolve([
{
remoteEntry: 'http://localhost:3000/remoteEntry.js',
remoteName: 'mfe1',
exposedModule: './Download',
displayName: 'Download',
componentName: 'DownloadComponent'
},
[...]
] as PluginOptions[]);
}
}
For the sake of simplicity, the LookupService
provides some hardcoded entries. In the real world, it would very likely request this data from a respective HTTP endpoint.
Dynamically Creating the Plugin Component
The workflow designer represents the plugins with a PluginProxyComponent
. It takes a PluginOptions
object via an input, loads the described plugin via Dynamic Module Federation and displays the plugin's component within a placeholder:
@Component({
selector: 'plugin-proxy',
template: `
<ng-container #placeHolder></ng-container>
`
})
export class PluginProxyComponent implements OnChanges {
@ViewChild('placeHolder', { read: ViewContainerRef, static: true })
viewContainer: ViewContainerRef;
constructor(
private injector: Injector,
private cfr: ComponentFactoryResolver) { }
@Input() options: PluginOptions;
async ngOnChanges() {
this.viewContainer.clear();
const component = await loadRemoteModule(this.options)
.then(m => m[this.options.componentName]);
const factory = this.cfr.resolveComponentFactory(component);
this.viewContainer.createComponent(factory, null, this.injector);
}
}
Wiring Up Everything
Now, it's time to wire up the parts mentioned above. For this, the workflow designer's AppComponent
gets a plugins
and a workflow
array. The first one represents the PluginOptions
of the available plugins and thus all available tasks while the second one describes the PluginOptions
of the selected tasks in the configured sequence:
@Component({ [...] })
export class AppComponent implements OnInit {
plugins: PluginOptions[] = [];
workflow: PluginOptions[] = [];
showConfig = false;
constructor(
private lookupService: LookupService) {
}
async ngOnInit(): Promise<void> {
this.plugins = await this.lookupService.lookup();
}
add(plugin: PluginOptions): void {
this.workflow.push(plugin);
}
toggle(): void {
this.showConfig = !this.showConfig;
}
}
The AppComponent
uses the injected LookupService
for populating its plugins
array. When a plugin is added to the workflow, the add
method puts its PluginOptions
object into the workflow array.
For displaying the workflow, the designer just iterates all items in the workflow array and creates a plugin-proxy
for them:
<ng-container *ngFor="let p of workflow; let last = last">
<plugin-proxy [options]="p"></plugin-proxy>
<i *ngIf="!last" class="arrow right" style=""></i>
</ng-container>
As discussed above, the proxy loads the plugin (at least, if it isn't already loaded) and displays it.
Also, for rendering the toolbox displayed on the left, it goes through all entries in the plugins
array. For each of them it displays a hyperlink calling bound to the add
method:
<div class="vertical-menu">
<a href="#" class="active">Tasks</a>
<a *ngFor="let p of plugins" (click)="add(p)">Add </a>
</div>
Conclusion
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.
Unsere Angular-Schulungen
