Consider supporting the execution of activators in web/service workers

[danielwiehl]

Is your feature request related to a problem? Please describe.

Many activators slow down application startup if configured to report readiness. Of course, the startup time depends on how fast the activators can report readiness. But even if having only fast activators, the startup time does not scale well.

An activator is a kind of microfrontend loaded into an invisible iframe. This approach is easy to understand and conforms with the mental model of microfrontends used in the SCION Microfrontend Platform. However, loading each activator into its iframe is time-consuming, especially noticeable if having 10 or more activators.

Describe the solution you'd like

Consider running activators (based on a flag in the activator capability) in web workers instead of iframes. The web workers would be started in the host and provide similar isolation as iframes.

For such activators, the micro applications provide a JavaScript file instead of a microfrontend HTML page. The host fetches the activator scripts and loads them into web workers. Since only scripts of the same origin can be loaded into a web worker, an indirection via 'blob:URI' would be necessary.

A limitation compared to iframe-based activators is that activator scripts are not executed under the same origin as the micro app, which means that data exchange via web storage between activator and the microfrontends is not available.

---

Note that in version 1.0.0-rc.13, the script would not be able to connect to the platform because the connection to the broker is established through the window hierarchy.

[ova2]

I like this idea. Another idea is to have a pool of web workers because without a pool you can freeze CPU with many web worker threads. This is what I would like to have in the Rendering Engine too (in the near feature to execute time-consuming operations in web workers). There are some ideas how to implement such pool.

I don't know but "scion/toolkit" is probably a better place for that. Maybe better: offer a shared "web workers pool service" as a microfrontend. In this case, "scion/microfrontend-platform" is a right place of course.

[k-genov]

Hi @ova2,

Thanks for your comment!

This issue concerns only the startup performance of activators and is not about providing an API to run arbitrary scripts in web workers.

We think that SCION should not provide a worker pool as API. Instead, a micro application or the host application can provide such capability. We try to keep the @scion/microfrontend platform as minimal as possible and provide only the most essential tools for microfrontend integration.

[ova2]

Hi @ova2,

Thanks for your comment!

This issue concerns only the startup performance of activators and is not about providing an API to run arbitrary scripts in web workers.

We think that SCION should not provide a worker pool as API. Instead, a micro application or the host application can provide such capability. We try to keep the @scion/microfrontend platform as minimal as possible and provide only the most essential tools for microfrontend integration.

Ok, sounds perfect for me. Sure, @scion/microfrontend is about a communication between microfrontends. I just wanted to say, be careful if you plan to run such scripts in workers in parallel - every worker requires a CPU thread. Probably the parallel runs should be limited to CPU processors: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/hardwareConcurrency If you have e.g. 8 processors, 4-8 workers could be started in parallel and when they finished all jobs, the next workers can be started and so on.