schweizerischebundesbahnen / scion-microfrontend-platform

SCION Microfrontend Platform is a TypeScript-based open-source library that helps to implement a microfrontend architecture using iframes.

SCION Microfrontend Platform	Projects Overview	Changelog	Contributing	Sponsoring

SCION Microfrontend Platform

SCION Microfrontend Platform enables you to successfully implement a framework-agnostic microfrontend architecture using iframes. It provides you fundamental APIs for microfrontends to communicate with each other across origins and facilitates embedding microfrontends using a web component and a router. SCION Microfrontend Platform is a lightweight, web stack agnostic library that has no user-facing components and does not dictate any form of application structure.

---

Quickstart

• What is a Microfrontend Architecture
  Learn more about the microfrontend design approach and its advantages for large-scale and long-lasting projects.

• How SCION Microfrontend Platform can help you
  Get an overview of the SCION Microfrontend Platform and learn how the platform can help you in implementing a microfrontend architecture.

• Installation
  Follow these steps to install the SCION Microfrontend Platform in your project.

• Getting Started
  Start with a gentle introduction to the essentials of the SCION Microfrontend Platform.

Documentation

• Reference Documentation
  Read our Developer Guide to learn more about the core concepts and configuration of the platform.

• API Documentation
  Consult our Public API documentation for a complete overview of the API.

Miscellaneous

• Announcements
  Get the latest news about the further development of the SCION Microfrontend Platform.

• Features
  Get an overview of existing and planned features of the SCION Microfrontend Platform.

• Versioning Policy
  Let us explain our versioning policy and why backward compatibility is important to us.

---

scion-microfrontend-platform's Issues

Migrate project workspace to Angular 13

Angular 13 was released in November 2021. Even though the SCION Microfrontend Platform is not dependent on the Angular framework, it uses Angular in its applications (e.g. devtools or testing app) and the Angular toolchain for the development of the project.

For more information, refer to https://github.com/angular/angular/blob/master/CHANGELOG.md#1312-2022-01-12 or https://blog.angular.io/angular-v13-is-now-available-cce66f7bc296.

Messages not published during platform shutdown

Describe the bug

Messages published during platform shutdown (e.g., in phase STOPPING) or in a beforeunload handler are not dispatched.

Sometimes, it is useful to publish the last will or similar, as follows:

    MicrofrontendPlatform.whenState(PlatformState.Stopping).then(() => {
      Beans.get(MessageClient).publish('last/will/topic', 'my last will');
    })

Intents should be transported to subscribed microfrontends only

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

Applications typically subscribe to intents in activator microfrontends. However, intents are broadcasted to each loaded microfrontend of the providing application, which causes unnecessary traffic on the messaging bus, especially when many microfrontends of that application are loaded.

Describe the solution you'd like

Intents should only be transported to microfrontends that have a respective subscription, thus analogous to topic subscriptions, where messages are transported to subscribed microfrontends only.

Migrate from TSLint to ESLint

TSLint has been deprecated in favor of ESLint. See palantir/tslint#4534 for more information.

In Angular 11, Angular CLI deprecated TSLint support in Angular CLI. The CLI recommends migrating to ESLint using the community driven ESLint builder. Refer to https://github.com/angular-eslint/angular-eslint#migrating-from-codelyzer-and-tslint for detailed instructions on how to migrate.

It is likely that the Angular CLI will officially provide a migration using the ng update command (ng update @angular/cli) in a future Angular 11 minor. Anyway, we want to use the opinionated ESLint setup from the Angular CLI, because it makes the migration to new Angular versions much easier. For this reason, I recommend to wait and see how things develop.

Provide convenience API for easy subscriptions to intents in the form of intent handlers

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

Subscribing to intents in an activator is such a common use case that the lib should provide a convenience API for it.

Describe the solution you'd like

The library provides a convenience API for easy subscriptions to intents in the form of intent handlers. An intent handler is like a manual subscription to the IntentClient to receive intents of a specific type and qualifier. The app would register intent handlers prior to starting the library. It would register the intent handler regardless of its microfrontend execution context, i.e., regardless of inside an activation context or not.

The registration could look as follows: Beans.register(IntentHandler, useClass: YourIntentHandler, multi: true).

For Angular apps, developers could even use a factory to let Angular construct the handler to profit from Angular dependency injection, as follows: Beans.register(IntentHandler, useFactory: () => rootInjector.get(YouIntentHandler), multi: true).

The IntentHandler API would look something like this.

export abstract class IntentHandler {

   public readonly type: string;
   public readonly qualifier?: Qualifier;

   public abstract onIntent(intentMessage: IntentMessage): void;
}

Please note to use an abstract class over an interface so it can be used as bean registration token.

On startup and if in the primary activator context, the platform would look up registered intent handlers and subscribe for respective intents.

Allow registering beans under a JavaScript Symbol

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

Beans are not limited to object instances but can also be primitives or even functions. In such cases, it is tedious to define an abstract class just to register the bean.

Describe the solution you'd like

Allow registering beans under the native JavaScript Symbol data type.

Allow metadata to be associated with a parameter

Does your feature request relate to a problem? Please describe it.

A capability can declare params to be passed along with the intent. Params can be either optional or mandatory.

We currently do not provide support for associating additional metadata with a parameter, such as a parameter's description, its data type, deprecation notes, and more.

Describe the desired solution.

The platform should allow metadata to be associated with a parameter.

Invalid characters in context key names cause the lookup promise to never resolve

Describe the bug

Contextual data cannot be associated with a key that contains forward slashes or that starts with a colon.

To Reproduce

Steps to reproduce the behavior:

1. Associate contextual data with a <sci-router-outlet> using the key a/b/c
2. In the microfrontend, look it up using the ContextService bean, as follows: ContextService.lookup('a/b/c')
3. The returned lookup Promise never resolves

Expected behavior

There should be no restrictions on naming context key names. Alternatively, it would be conceivable that at least an error is thrown when using invalid characters in the key.

Environment

SCION Microfrontend Platform version: 1.0.0-beta.8

Prevent default action of bubbled keystroke event

Describe the bug

When registering keystrokes on a SCION router outlet:

<sci-router-outlet keystrokes="keydown.control.5"></sci-router-outlet>

The event bubbles from the microfrontend to the host. However, the default action is still triggered. In this case with Ctrl+5 the Chrome browser switches to the fifth browser tab, even though the host app prevents the default action of the bubbled event.

Expectation

If the sci-router-outlet configures shortcuts with the keystrokes attributes, the events are supposed to be handled by the host app, therefore the default action should always be prevented in the microfrontend.

Requests not handled after hot-code replacement

Describe the bug

It turned out that after reloading the application due to hot code replacement, requests sent from a microfrontend to its activator may not be handled. This applies to both, intent- and topic-based requests.

When a micro application reloads during development, e.g., due to a code change, both its activators and regular microfrontends will reload at the same time. When the microfrontend initiates a request-reply communication with its activator, the handler may not yet be installed in the activator.

This problem does not exist for regular startups since the host app waits for all activators to complete initialization. However, in the process of hot code replacement, the host app is already operational and activators and regular microfrontends will boot simultaneously, causing the described bug.

There are several ways to address this problem:

• Add support for retained intents
• Wait to dispatch intents and messages to activator clients until they signal readiness
• ...

Environment

Please complete the following information:

• SCION Microfrontend Platform version: 1.0.0-beta.15

Update project workspace to Angular 10

The project workspace of the SCION Microfrontend Platform has a dependency on Angular used by the internal testing app and to bundle the project using ng-packagr. At runtime, the platform has no dependency on the Angular framework.

Migrate Vercel deployments to the updated URL format (before Feb. 20, 2021)

Describe the bug

Vercel, which we use to deploy our test applications and documentation, will change its URL format to be more consistent. Most notably, Vercel will disable URLs that end with "now.sh". Instead, projects should switch to URLs that end with "vercel.app".
The change will go into effect on February 20, 2021.

See https://vercel.com/changelog/urls-are-becoming-consistent for more information.

Allow to configure shadowMode (closed/open) of web-components

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

Due to the fact that each microfrontend loaded via sci-router-outlet is wrapped inside a web-component with a 'closed' shadow-root, it is currently impossible to test the UI with e.g. selenium.

Describe the solution you'd like

When using scion, it should be configurable if web-components should have a closed (default) or open shadow-root.
(Or maybe even if there shouldn't be used any web-components at all?)

Describe alternatives you've considered

There is a possibility to gain access to elements inside a closed shadow-root by running the following code snippet:
const iframe = await browser.executeScript('return arguments[0].iframe', this._pageFinder.$('sci-router-outlet').getWebElement()) as WebElement
However, selenium still struggles to execute basic operations (e.g. clicks on elements fail!)

Propagate error if no connection to the message broker could be established

Describe the bug

When starting the platform, the returned Promise does not reject if no connection to the message broker could be established, e.g., after the maximal timeout has expired, or in case of rejection by the broker.

• MicrofrontendPlatform.startHost(...): Promise<void>
• MicrofrontendPlatform.connectToHost(...): Promise<void>

Expected behavior

The Promise returned by MicrofrontendPlatform.startHost(...) and MicrofrontendPlatform.connectToHost(...) should reject if no connection to the message broker could be established.

• SCION Microfrontend Platform version: 1.0.0-beta.7

Ensure to compile with TypeScript strict checks enabled

In order to support a wide range of projects, the SCION Microfrontend Platform library should pass TypeScript's strict checks.

See https://www.typescriptlang.org/tsconfig for available strict checks.

Allow passing params in an intent that do not affect intent routing

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

A capability is addressed by its type and optionally by a qualifier to distinguish different capabilities of the same type. Both type and qualifier affect intent routing.

Sometimes, however, it may be useful to pass additional key-value pairs together with the intent, which in contrast have no effect on the intent routing. Of course, you could use message headers or put them into the intent payload. But, headers and payload are not part of the intent itself, but of the message, i.e., they are not declared in the public API of the capability.

Params would allow to use them for substitution, e.g., when using OutletRouter to replace path segments or query params in the microfrontend path.

Imagine an app to provide the following microfrontend capability:

{
      "type": "microfrontend",
      "qualifier": {"entity": "person", "id": "*"},
      "params": {"readonly": "*"}, // not yet supported
      "private": false,
      "properties": {
        "path": "/person/:id?readonly=:readonly"
      }
    }

When receiving a respective intent, besides qualifier entries, we could also use params to substitute placeholders in the microfrontend URL, as follows:

    Beans.get(IntentClient).observe$({type: 'microfrontend', qualifier: {entity: 'person', id: '*'}})
      .subscribe(intentMessage) => {
        Beans.get(OutletRouter).navigate(intentMessage.capability.properties.path, {params: {...intent.qualifier, ...intent.params}});
      });

Describe the solution you'd like

• Add optional params dictionary to the capability and intent model objects.
• Change OutletRouter#navigate to throw an error if named parameters are missing.

SCION Platform Lifecycle after Activator Initialization

Is your feature request related to a problem?

We are using multiple micro-frontends. As soon as the application is started, we send an intent to a micro-frontend, which is handled by the Activator of the micro-frontend. The activator then uses the OutletRouter to display a page.

Currently the host application does not know, if there is somebody listening to the capabilities described in the client's manifest.json. This leads to sent intents being lost, when the intents are sent to early.

Describe alternatives you've considered

Currently we are send a topic message per micro-frontend after the activator is completely initialized. E.g.

Beans.get(MessageClient)
                .publish('activated/casa-angebot-web', null, {retain: true});

And the host application waits until it has received activated/* messages from every necessary micro-frontend before triggering the intent for navigation.

Describe the solution you'd like

There are multiple possible solutions:

• Maybe some of the work (or all?) done by the workaround can be handled by the SCION platform.
• Maybe there is even a possiblity to know if somebody is really handling a capability, so sent intents are not lost.

Extract the platform config loading logic from ManifestCollector in a separate bean

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

Currentrly the ManifestCollector is responsible for:

• loading the platform config
• fetching and registering the manifests of the micro apps
  https://github.com/SchweizerischeBundesbahnen/scion-microfrontend-platform/blob/master/projects/scion/microfrontend-platform/src/lib/host/manifest-collector.ts#L36

Describe the solution you'd like

Flowing the separation of concerns principle it would be better to split the bean and extract the platform config loading logic into a separate bean e.g. PlatformConfigLoader

Describe alternatives you've considered

Additional context

Check the run level configuration. The ManifestCollector uses runlevel 0, the PlatformConfigLoader should be loaded before the ManifestCollector .

Consider adding wildcard support for unregistering capabilities

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

The API for unregistering capabilities does not support wildcards, which seems to be intentional according to the method's TypeDoc. Thus, to unregister multiple capabilities, the application first has to look up matching capabilities and then unregister them, one by one, using their ids.

The method's TypeDoc says: If given a qualifier in the filter, wildcards, if any, are not interpreted as wildcards, but as exact values instead.

What was the reason for not supporting wildcards? This restriction is very tedious and error-prone and also leads to potentially many API calls.

Describe the solution you'd like

It would be convenient to support wildcards for unregistering capabilities.

Migrate to Angular 12

Angular 12 was released in May 2021. Even though the SCION Microfrontend Platform is not dependent on the Angular framework, it uses Angular in its applications (e.g. devtools or testing app) and the Angular toolchain for the development of the project.

For more information, refer to https://github.com/angular/angular/blob/master/CHANGELOG.md#1200-2021-05-12 or https://blog.angular.io/angular-v12-is-now-available-32ed51fbfd49.

Named parameters substition does not work with falsy values

Describe the bug

Beans.get(OutletRouter).navigate(`${basePath}/a?orderId=:orderId&flag=:flag`, {
      params: new Map().set('orderId', 0).set('flag', false)
   });
});

does not substitue the orderId and the flag, because the values are falsy. Instead the URL still contains the keys :orderId and :flag.

Expected behavior

If the key is present in the params, the value provided should always be used, even if the value is falsy.

Stabilize unit tests

The unit tests often fail on GitHub CI due to flaky tests with the following error:

 [BrokerDiscoverTimeoutError] Message broker not discovered within the 250ms timeout. Messages cannot be published or received.

Support application-private messaging

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

A microfrontend can communicate with its application activators, for example, using topic-based messaging. The problem is that those messages can also be received by other applications, or that other applications can respond to those requests, and not necessarily maliciously, for example in the case of name collisions.

Describe the solution you'd like

The platform should support application-private messaging, as follows:

• A message can be marked as application-private by setting a flag in the publishing options.
• Private messages are only routed between instances of the same application, thus other applications cannot receive private messages of other applications nor publish messages to private topics of other applications.
• Applications may define the same private topics. Still, private messages must never be routed between applications.

Add generic to `ManifestService.registerCapability` method

Specifying the type of the capability when registering it would increase type safety.

Example:

Beans.get(ManifestService).registerCapability<AlertCapability>({
  type: 'alert',
  properties: {
    icon: 'ringer',
    text: '...',
    cssClass: 'e2e-alert',
  },
});

Consider using the micro app's communication channel for the library to communicate with the broker

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

It may be too academic to have a separate communication channel for library-internal communication. Instead, the library should use the same channel as the micro app. Then, however, for intent-based communication, the library would act on behalf of the micro app, which would be fine.

Motivation

The separation of communication leads to significant complexity without clear advantages. If only a single channel is used, the second broker gateway including its iframe could be removed, which is also a prerequisite for implementing Issue #14.

Excessive number of change detection cycles

Describe the bug

It turned out that the platform causes an excessive number of change detection cycles just by moving the mouse over the application.

It seems that it is related to messaging. Because when you set a breakpoint, the following error message occurs after 10s.

[MessageDispatchError] Broker did not report message delivery state within the 10000ms timeout. [envelope={"transport":"sci://microfrontend-platform/client-to-broker","channel":"topic","message":{"topic":"ɵworkbench/views/view.1/active","retain":true,"headers":{"ɵMESSAGE_ID":"83499580-ab3f-4e49-938c-0760484fbfab","ɵTIMESTAMP":1611216897729,"ɵAPP_SYMBOLIC_NAME":"workbench-host","ɵCLIENT_ID":"2962a46f-642b-40fc-b977-5c2db51c9138"},"body":true}}]

To Reproduce

Steps to reproduce the behavior:

1. Implement DoCheck Angular lifecycle hook in app.component.ts and log each invocation.
2. See that it is called just when moving the mouse over the app

Expected behavior

Moving the mouse does not trigger a change detection run.

Environment

Please complete the following information:

• SCION Microfrontend Platform version: 1.0.0-beta.9

Increase throughput of message broker

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

When there is a lot load on the message bus, some intents get rejected with this error:

[MessageDispatchError] Broker did not report message delivery state within the 10000ms timeout.

The respective timeout could be increased in 'MicroApplicationConfig' but this still leaves us with a laggy application.

Reproducer (tested with Google Chrome Version 92.0.4515.131):

capability: 
    {
      "type": "to-uppercase",
      "requiredParams": [
        "payload"
      ],
      "description": "Converts the provided payload to uppercase."
    },

intent-handler:
    this._intentClient.onIntent({type: 'to-uppercase'}, ({intent})=> {
      return of((intent.params.get('payload') as string).toUpperCase());
    });

invocation:
    for (let i = 0; i < 1000; i++) {
      this._intentClient.request$({type: 'to-uppercase', params: new Map().set('payload', 'lorem ipsum')})
        .subscribe((message) => console.log('>> toUpper: ', message.body));
    }

Describe the solution you'd like

Validate the following hypothesis: "The problem is the number of single messages but not the combined size of all messages."

Try to increase throughput by implementing something like this:

• When publishing intents detect whether there currently is a high-load situation.
  • If so: bundle intents (and possibly also replies) for publishing
  • If not: do not bundle intents (avoid additional delay)

Consider improving performance of sending data via Transferable Objects

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

SCION Microfrontend Platform exchanges data (messages, intents) via the window.postMessage mechanism, which uses the structured cloning algorithm to transfer data. Since the data is copied, this can lead to noticeable performance degradation when transferring large amounts of data.

Describe the solution you'd like

Consider transferring data using Transferable Objects.

Additional context

• https://developer.mozilla.org/en-US/docs/Glossary/Transferable_objects
• https://www.html5rocks.com/en/tutorials/workers/basics/#toc-transferrables
• https://developers.google.com/web/updates/2011/12/Transferable-Objects-Lightning-Fast

Move bean manager to @scion/toolkit

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

The bean manager is not directly related to the SCION Microfrontend Platform and should be moved to the @scion/toolkit, so that other libraries and applications can use it as well.

For example, we have started developing an extension to the SCION Workbench that allows micro applications not running in the workbench to contribute views and behavior in the form of micro frontends. Since this is a pure TypeScript library, we also need a way to manage and lookup beans.

Describe the solution you'd like

The bean manager can be used independently of the SCION Microfrontend Platform.

Platform does not start if a micro application hangs during activation

Describe the bug

The workbench stays on the startup animation indefinitely if one of the registered micro frontends runs into an error during startup/activation

To Reproduce

1. Start an incognito window in Google Chrome (currently not reproducible on Microsoft Edge)
2. Navigate to https://tms-test.sbb.ch/
3. Observe that the startup animation does not go away. The reason seems to be the error in the caparout micro app during its activation (see console log)

Expected behavior

Activation errors in registered micro apps should be handled gracefully by the plattform, i.e. startup should complete with all micro apps loaded that could successfully be started. In this case: workbench is loaded with all micro apps except caparoute.

If this is not possible, there should be a timeout after which the user is informed that startup failed, with a reason. In this case: "Application could not be started due to error in micro app caparoute"

Screenshots

Environment

Please complete the following information:

• SCION Microfrontend Platform version: Version currently deployed on tms-test.sbb.ch
• Browser: Chrome Version 91.0.4472.124
• OS: Windows 10
• Device: Desktop

Provide access to resolved capability in intent interceptor

An interceptor allows intercepting intents prior to dispatching to consumers. The interceptor receives the intent as issued, but not the resolved capability(-ies).

For some use cases, it is necessary to also get a reference to the target capability(s), e.g., to perform message validation.

Consolidate NPM scripts in package.json

Scripts in package.json should be organized the same way as in SCION Workbench project.

Warning when building a micro app because of `semver` module

Describe the bug

SCION Microfrontend Platform depends on the module semver to detect version mismatches between host and clients. Unfortunately semver is not based on the ES2015 module system, which can lead to warnings in the build and a larger bundle size.

To Reproduce

Steps to reproduce the behavior:

1. Start a micro app
2. See the following error: Warning: ... depends on 'semver'. CommonJS or AMD dependencies can cause optimization bailouts.

Expected behavior

Replace semver with another third-party library or implement the necessary functionality directly in the platform.

Environment

Please complete the following information:

• SCION Microfrontend Platform version: 1.0.0-rc.3

Testing URL

Hello,

Well, first of all this is not a complaint, it's more like a question.

In the past, you had a URL where we could demonstrate the capabilities of the framework that you are building, this was the URL: https://scion-microfrontend-platform-app-1.now.sh/#/testing-app/browser-outlets;count=3.

Do you still have such testing URL? Can you please share it somewhere in the documentation or point me to a direction?

And I'll end with the assumption that you guys have been safe during this period! :)

Thanks,
Bogdan.

Simplify configuration of the platform host

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

Starting the platform host via MicrofrontendPlatform.startHost allows the configuration to be passed in various ways, which is confusing. For example, if the configuration needs to be loaded asynchronously, e.g. over the network, this can simply be done before the microfrontend platform is started, .i.e., the platform does not need to support the concept of a loader. On the other hand, it would be a great help if the manifest of the host could be passed along directly via the config and does not have to be served as JSON.

DevTools for SCION Microfrontend Platform

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

With a large number of micro applications and capabilities, you can quickly lose the big picture. This is where DevTools can help the developer to see which capabilities are available and how the applications depend on each other.

Describe the solution you'd like

A DevTools microfrontend that developers can plug in when needed.

Remove ES2015 import cycles

Describe the bug

We have some ES2015 import cycles which should be removed.

Problem

In microfrontend-platform.ts we register platform-specific beans. Some of those beans then import microfrontend-platform.ts to interact with platform states, e.g. to wait for the platform to finish startup.

Example: application-activator.ts -> microfrontend-platform.ts -> application-activator.ts

Environment

Please complete the following information:

• SCION Microfrontend Platform version: 1.0.0-beta.7

Drop support for the wildcard entry {"*": "*"} in the capability's qualifier

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

The qualifier of a capability is used to qualify multiple capabilities of the same type, supporting wildcards in both, the qualifier key and the qualifier value.

If adding the wildcard entry {"*": "*"} to the qualifier, the capability will also match intents with additional qualifier entries. Additional entries do not affect intent routing and are used to pass additional data with the qualifier, such as a flag. However, with the introduction of params #44, the capability can declare optional and required parameters to be passed along with the intent, making the wildcard qualifier entry obsolete.

Describe the solution you'd like

Drop support for the wildcard entry {"*": "*"} in the capability's qualifier as this is no longer the recommended way to pass additional parameters. However, the wildcards (* and ?) should still be supported at the qualifier value level, or when looking up or unregistering capabilities using the ManifestService.

Allow monitoring messages and intents in DevTools

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

To facilitate debugging, it would be helpful to see the sent messages and intents in DevTools.

Describe the solution you'd like

DevTools provide a monitoring page that displays the messages and intents sent by any application. It should be possible to subscribe to specific messages and intents or to see all traffic.

Migrate end-to-end tests from Protractor to another end-to-end testing framework

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

Protractor has been deprecated and Angular will drop support in Angular v15 (end of 2022).

Describe the solution you'd like

We have a lot of end-to-end tests that need to be migrated. We use the PO (Page Object) pattern to not depend on the Protractor API in the actual specs. This comes in handy for migration, so we should choose a test framework that supports this approach.

The goal should be to migrate our tests and not just throw them away and rewrite them. Otherwise, we run the risk of losing important tests.

Additional context

• Protractor deprecation note: angular/protractor#5502
• Playwright vs Cypress: https://medium.com/sparebank1-digital/playwright-vs-cypress-1e127d9157bd

Protractor fails running e2e tests due to version mismatch between Chromium and Selenium webdriver (chromedriver)

Describe the bug

By default, Protractor automatically downloads the latest Selenium webdriver for Chromium at startup, causing a version mismatch error when a new webdriver version is released.

This problem is discussed here: angular/protractor#4695

Expected behavior

Configure Protractor to use the chromedriver compatible with the Chromium provided by Puppeteer.

Error

DevTools listening on ws://127.0.0.1:57600/devtools/browser/dd96c81d-dce7-4ab0-b6ad-26178a9c549c
[09:23:23] E/runner - Unable to start a WebDriver session.
[09:23:23] E/launcher - Error: SessionNotCreatedError: session not created: This version of ChromeDriver only supports Chrome version 85
  (Driver info: chromedriver=85.0.4183.38 (9047dbc2c693f044042bbec5c91401c708c7c26a-refs/branch-heads/4183@{#779}),platform=Windows NT 10.0.17134 x86_64)
    at Object.checkLegacyResponse (C:\devsbb\git\scion\scion-workbench\node_modules\selenium-webdriver\lib\error.js:546:15)
    at parseHttpResponse (C:\devsbb\git\scion\scion-workbench\node_modules\selenium-webdriver\lib\http.js:509:13)
    at doSend.then.response (C:\devsbb\git\scion\scion-workbench\node_modules\selenium-webdriver\lib\http.js:441:30)

Support for deprecating capabilities

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

The platform should provide API for marking a capability as deprecated, similar to deprecating params of a capability.

Describe the solution you'd like

• Capability provides deprecated property, similar to ParamDefinition#deprecated
• Deprecated capabilities are visualized in devtools (e.g. strike through)
• Intentions to deprecated capabilities are visualized in devtools (e.g. strike through)
• Logs warning if providing/using deprecated capability

Provide API to listen to the progress of the startup process

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

The platform startup may take some time, especially when waiting for activators to signal readiness. The platform should provide an API to listen to the progress of the startup process so that the progress can be visualized with a progress bar or similar.

Describe the solution you'd like

The API should continuously report the current status of the startup process. It should not be limited to the progress of the activators but should apply generally to the entire startup progress of the platform.

Check if the extra iframe is really necessary for the microfrontend-broker communication

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

Each microfrontend uses an extra iframe to communicate with the broker. While an extra iframe may be required in the host application for correct dispatching of intents to the host application and host platform, it may be redundant in microfrontends.

Describe the solution you'd like

Microfrontends already run in a dedicated iframe, so it should be examined if this extra iframe is still needed for microfrontends. Because using a separate iframe for communicating with the broker doubles the total number of iframes in the application.

Upgrade Testing App and DevTools to Angular 11

Angular 11 version is available now. Testing App and DevTools should be updated to be compatible with Angular 11.

Refer to https://angular.io/guide/updating-to-version-11 for more information.

Write Security Whitepaper

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

Is it secure to use the SCION Microfrontend Platform? The host application integrates applications from different origins by sending messages via the browsers messaging infrastructure. Can these messages be intercepted? Are there other potential vulnerabilities to consider?

Describe the solution you'd like

Write a document detailing how the SCION Microfrontend Platform secures itself and its hosted applications.

Simplify the integration of DevTools into workbench-enabled applications

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

The SCION Workbench allows the integration of microfrontends as views by issuing a view intent. To open the DevTools as view microfrontend, an extra manifest with the view capability needs to be registered instead of pointing directly to the manifest of the DevTools micro application. In the manifest, the base path has to point to the effective DevTools application.

Describe alternatives you've considered

The DevTools are part of the SCION ecosystem. Therefore,w they should provide a view capability in their manifest for seamless integration into a workbench-enabled application. Then, the extra manifest would no longer be necessary.

Host platform startup fails if loading the manifests exceeds the broker discovery timeout

Describe the bug

Host platform startup fails if loading the manifests exceeds the broker discovery timeout.

To Reproduce

Steps to reproduce the behavior:

1. Delay loading manifests in the manifest collector manifest-collector.ts, e.g., await new Promise(noop);
2. Start the platform in the host: MicrofrontendPlatform.startHost(...)
3. See the errors in the log after 10s (after default brokerDiscoverTimeout elapses)

Expected behavior

Host platform startup should not fail if fetching the manifests takes longer than brokerDiscoverTimeout. The connection to the broker should only be established after the manifests have been loaded, which is after runlevel 1.

Environment

Please complete the following information:

• SCION Microfrontend Platform version: 1.0.0-beta.7

Separation of topic-based and intent-based communication APIs

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

The MessageClient provides API for both topic-based and intent-based communication. This can lead to confusion. It would be better to separate these two APIs.

Describe the solution you'd like

Separation of the two APIs into MessageClient and IntentClient.

Platform fails to start if not starting it on behalf of a micro app

Describe the bug

If the host platform is started not on behalf of a micro app (that is, without specifying a micro app as the second parameter), and if micro apps provide activators, the startup of the host platform fails.

Error: The startup rejects with a NullBeanError when the platform is trying to mount activator microfrontends.

Expected behavior

The platform can be started without errors.

Environment

Please complete the following information:

• SCION Microfrontend Platform version: [1.0.0-beta.3]
• Browser: [Chrome 83]
• OS: [Windows 10]
• Device: [Desktop]