Plugin Architecture -Angular — Is it even possible?
By: Wael Yousef
Tags: Plugin Architecture, Continuous Delivery, Future Architecture, Angular, Micro Frontends

Technology facts:

Most of the known browsers announced they will run on Chromium. Accordingly, V8 became the base engine for most of the known browsers:

https://blog.sessionstack.com/how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e

https://blog.sessionstack.com/how-javascript-works-inside-the-v8-engine-5-tips-on-how-to-write-optimized-code-ac089e62b12e JavaScript Frameworks are rapidly growing. each 6 months a new version of these frameworks is coming up.

front-end became smarter and more complex than before.

PWA

https://medium.com/@deepusnath/4-points-to-keep-in-mind-before-introducing-progressive-web-apps-pwa-to-your-team-8dc66bcf6011

https://medium.com/@deepusnath/4-points-to-keep-in-mind-before-introducing-progressive-web-apps-pwa-to-your-team-8dc66bcf6011 SPA

Single-page-application help keep the user in one and comfortable web space where content is presented to the user in a simple, easy and workable fashion.

https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58

SPA, requires all the pages “projects” to be available during the bundle time “ and that will defeat the concept of operating independently“.

Technical facts:

Each project’s team would like to operate independently.

Each team has their own Angular project.

Navigating between the projects will be through web-projects “which is affecting end user experience, user must wait to bootstrap the platform each time the user is navigating from page to another, especially for enterprise apps where hundreds of developers are contributing to large suit.

All the teams must be internally connected to tackle all the issues otherwise they are re-inventing the wheel in each project.

Every time the release is happening in the Prod, all the clients will get affected by the new deployed code “either positively or negatively”.

We must have environmental setup to apply Blue-Green release “which is too costly “.

What is Micro-Front-end Architecture?

Extending Microservice paradigms to web development.

Build a feature-rich and powerful browser application, Single page app, on top of a micro service architecture layer.

Micro-Frontend is a composition of features owned by independent teams. Each team has a distinct business functionality.

What is plugin architecture?

A plugin architecture is an architecture that will call external code at certain points without knowing all the details of that code in advance.

Plugins must follow some sort of convention to work. This can be the likes of a text format, a network protocol, or an interface.

They must be discoverable and usable by the main program or package in some way, whether they follow a library convention and are located in a particular directory or whether someone has to edit a configuration file to point at them.

“It’s software that allows you to add capabilities by adding something after the fact, allowing it to work as if it were part of the original system. Usually, the original developer publishes an interface or some kind of development kit that lets others develop plugins for their software”.

Why do we need Plugin architecture? and how it will help us to achieve our end goal?

Goals & Objectives

Reduce the back-forth between the front-end to navigate between the projects.

Routing should be front-end based and according to the user’s activities.

Projects/Functional teams should be able to operate independently.

User should see only one page and navigation between the projects will be smoothly without any page refresh “post back”.

Each client may have a different version and the upgrade to the latest version would be through metadata and no need for weekend production release or environmental setup.

Continuous production releases with ZERO downtime.

To achieve these goals:

We need to implement the entire solution as SPA.

Use Micro-frontend to implement each business functionality as independent monolithic component and communicate with other components through a well-defined interface.

Use Plugin architecture to be able to build & release each component independently and inject it into any project based on metadata.

Use Metadata to be able to define:

✓ Routing based on the end user’s activities

✓Plugin-injector (manager).

✓Project Entry plugin

✓Plugins metadata for each project

✓Workflow metadata

✓Rule engine metadata

✓http/rest APIs metadata

✓Layout designer metadata

o Since the platform scalable, any custom plugin can be implemented and injected through metadata

Technical issue/difficulties:

Angular CLI/Webpack:

✓Require all the project components to be available during the bundle time.

✓Harmony import/export by webpack requires all the modules to be available during the bundle time.

✓Webpack declare all the classes/services/components and give them module_Ids to be used later in other components/modules withing the same project.

✓IIFE & Closure compiles will not accept any external piece of code that does not have the same signature.

✓How we can make sure the module ID is unique within the bundle file otherwise any new plugin may break the entire project.

✓Require all the project components to be available during the bundle time. ✓Harmony import/export by webpack requires all the modules to be available during the bundle time. ✓Webpack declare all the classes/services/components and give them module_Ids to be used later in other components/modules withing the same project. ✓IIFE & Closure compiles will not accept any external piece of code that does not have the same signature. ✓How we can make sure the module ID is unique within the bundle file otherwise any new plugin may break the entire project. Since the plugin is an external file, how can we load it?

✓SystemJs vs requireJs.

✓SystemJs vs Webpack.

✓SystemJs vs requireJs. ✓SystemJs vs Webpack. Even if the file loaded properly, how the file will get injected into the project?

How can we load the plugin only one time and reuse wherever it is required, even multiple pages?

What is the format of the plugin AMD, CommonJs, UMD or webpack chunk file?

How the plugins can refer each other internally without breaking the logic or adding any additional code to make it work.

What about AOT, IVY, JIT?

How angular compiler ngc will work if all of these are done?

Functionally, how can we release a plugin?

Can we introduce versioning-based plugin?

Swap between Prod & Dev modes.

Enable source map.

How tree-shaking will work here?

Even if all the mentioned issues are solved, how the runtime will work? how can we load any plugin on the fly and inject it into the DOM and make it work as if it was a part of the project initially and not loaded as a plugin?

If Solution is already exist, what benefit we will get from that:

We can implement any plugin independently.

Release each plugin based on version number.

Utilize the metadata to load the version defined for a particular Project/client.

The entire Suit will act as SPA because the only angular project will act like a bootstrapper/shell.

In addition to the above points: