This chapter introduces the topic-based communication for exchanging data and sending events between micro applications.

Topic-based messaging allows publishing a message to a topic, which then is transported to consumers subscribed to the topic. Topics are case-sensitive and consist of one or more segments, each separated by a forward slash. Consumers can subscribe to multiple topics simultaneously by using wildcard segments in the topic.

The platform provides the MessageClient service for sending and receiving messages on a common topic. You can obtain this service from the platform’s bean manager as follows: Beans.get(MessageClient).

When publishing a message, the message is transported to all consumers subscribed to the topic. The topic must be exact, thus not contain wildcards. Optionally, you can pass options to control how to publish the message or set message headers. Transfer data to be carried along with the message (i.e. the message body) can be any object which is serializable with the Structured Clone Algorithm.

The following code snippet shows how to publish a message to a topic destination.

A microfrontend can receive messages published to a topic as following.

A microfrontend can subscribe to multiple topics simultaneously by using wildcard segments in the topic. If a segment begins with a colon (:), then the segment acts as a placeholder for any segment value. Substituted segment values are then available via the params property of the received message.

For example, subscribing to the topic myhome/:room/temperature receives messages published to the topics myhome/kitchen/temperature and myhome/livingroom/temperature.

The platform supports publishing a message as a retained message. Retained messages help newly subscribed clients to get the last message published to a topic immediately upon subscription. The broker stores one retained message per topic, i.e., a later sent retained message will replace a previously sent retained message. To delete a retained message, send a retained message without payload to the topic. Deletion messages are not transported to subscribers.

The following example shows how to publish a message as a retained message.

The platform allows publishing a message with message headers, which the receiver then can read. A message header can contain any data that is serializable with the Structured Clone Algorithm.

The recipient can then access the message headers via the headers property on the received message, as illustrated in the following example.

The platform facilitates the request-response message exchange pattern for synchronous communication.

The communication is initiated by the publisher by sending a request (instead of publishing a message). The recipient can then respond to the request. Just as in JMS (Java Message Service), the platform sets a ReplyTo message header on the message, which contains the topic of a temporary inbox where the replier can send replies to. The inbox is destroyed when the publisher (requestor) unsubscribes.

The following code snippet shows how to initiate a request-response communication and receiving replies.

Similar to publishing a retained message, a request can also be marked as retained, instructing the broker to store it in the broker and deliver it to new subscribers, even if they subscribe after the request has been sent. Unlike retained messages, retained requests are not replaced by later retained requests or messages and remain in the broker until the requestor unsubscribes.

The following code snippet illustrates how to send a retained request.

The following code snippet shows how requests are received and answered. You can reply to a request by sending one or more replies to the replyTo topic contained in the request’s headers.

As an illustration, in the following example, a temperature sensor is subscribed to for each request. When the sensor emits the temperature, the temperature is sent to the requester. The sensor Observable is a hot Observable, meaning it never completes, emitting the new temperature with every temperature change.

The message client provides the onMessage method as a convenience to the observe$ method. Unlike observe$, messages are passed to a callback function rather than emitted from an Observable. Response(s) can be returned directly from the callback. It supports error propagation and request termination. Using this method over observe$ significantly reduces the code required to respond to requests.

For each message received, the specified callback function is called. When used in request-response communication, the callback function can return the response either directly or in the form of a Promise or Observable. Returning a Promise allows the response to be computed asynchronously, and an Observable allows to return one or more responses, e.g., for streaming data. In either case, when the final response is produced, the handler terminates the communication, completing the requestor’s Observable. If the callback throws an error, or the returned Promise or Observable errors, the error is transported to the requestor, erroring the requestor’s Observable.

This chapter introduces the intent-based communication for controlled collaboration between micro applications.

Intent-based messaging enables controlled collaboration between micro applications, a mechanism known from Android development where an application can start an activity via an Intent (such as sending an email).

This kind of communication is similar to the topic-based communication, thus implements also the publish-subscribe messaging pattern. Both communication models allow messages to be sent between instances of applications. However, intent-based messaging goes beyond "simple" messaging and is the basis for controlled collaboration. Controlled collaboration means that communication flows are explicit and must be declared in the manifest. For the sending application, this means it must declare an intention in its manifest, and for the receiving application, it must provide a capability. The declaration of capabilities in the manifest file is similar to the OpenAPI specification for REST APIs - it defines the contract for the provided interaction.

The advantage of this kind of communication becomes apparent when the number of cross-application communications grows to provide an overview of the communication flows in the system. For example, in case of a breaking change in the message format, you can clearly identify your communication peers to coordinate the migration. Further, a capability is more than "simply" a messaging endpoint. A capability can be thought of as an API that can be invoked via intent, browsed via the DevTools or programmatically via the Intention API. A capability can specify parameters which must be passed along with the intent. Parameters are part of the contract between the intent publisher and the capability provider.

In topic-based communication, messages are published to a topic destination. In intent-based communication, on the other hand, the destination are capabilities, formulated in an abstract way, consisting of a a type, and optionally a qualifier. The type categorizes a capability in terms of its functional semantics. A capability may also define a qualifier to differentiate the different capabilities of the same type. The type is a string literal and the qualifier a dictionary of key-value pairs. To better understand the concept of the qualifier, a bean manager can be used as an analogy. If there is more than one bean of the same type, a qualifier can be used to control which bean to inject.

The terminology and concepts are explained in more detail in the Intention API chapter. This chapter focuses on communication and illustrates how to send and receive intents using the IntentClient, which is available from the Platform’s bean manager.

An application must declare an intention in its manifest in order to interact with a capability.

To illustrate the concept of intent-based messaging, we will look at an IoT example with sensors controlling room temperature modeled as capabilities. To set the temperature of a room, we send an intent to the room sensor. To get the room temperature, we query the sensor using request-response.

To learn more about an intention, see chapter What is an Intention? in Intention API.

An application can publish intents for intentions declared in its manifest. The platform transports the intent to applications that provide a fulfilling capability. Along with the intent, the application can pass transfer data, either as payload, message headers or parameters. Passed data must be serializable with the Structured Clone Algorithm.

In the following example, we send an intent to the temperature sensor in the kitchen to set the temperature to 22°C.

To learn more about an intent, see chapter What is an Intent? in Intention API.

The platform supports publishing an intent as a retained intent. Retained intents help newly subscribed clients to get the last intent published for a capability immediately upon subscription. The broker stores one retained intent per capability, i.e., a later sent retained intent will replace a previously sent retained intent. To delete a retained intent, send a retained intent without payload to the same destination. Deletion intents are not transported to subscribers.

In the following example, we set the kitchen temperature to 22°C. We send a retained intent since the kitchen temperature sensor may not be available yet. As soon as it connects to the platform, it will receive the intent for adjusting the temperature.

An application can make functionality available to other applications via capabilities. Typically, capabilities are declared in the manifest, but can also be contributed programmatically using the ManifestService.

The following code snippet illustrates the declaration of the kitchen temperature sensor as a capability in the manifest.

To learn more about a capability, see chapter What is a Capability? in Intention API.

Intents are transported to applications that provide a fulfilling capability and are typically subscribed to in an activator. An activator is a special microfrontend that an application can provide. Activators are loaded when starting the host application and run for the entire application lifecycle. An activator microfrontend is special in that it is never displayed to the user. Learn more about activator in the chapter Activator.

The following code snippet illustrates how to receive intents.

The platform facilitates the request-response message exchange pattern for synchronous communication.

The communication is initiated by the requestor by sending a request. The recipient can then respond to the request. Just as in JMS (Java Message Service), the platform sets a ReplyTo message header on the intent, which contains the topic of a temporary inbox where the replier can send replies to. The inbox is destroyed when the requestor unsubscribes.

The following code snippet illustrates how to initiate a request-response communication via intent-based messaging and receiving replies. To explain this type of communication, let’s take a client that requests the current kitchen temperature.

The following code snippet shows how requests (intents) are received and answered. You can reply to an intent by sending one or more replies to the replyTo topic contained in the intent’s headers. Please note to send replies via the MessageClient.

For illustration purposes, for each request, the following example subscribes to the temperature sensor. The sensor observable never completes and continuously emits when the temperature changes.

The intent client provides the onIntent method as a convenience to the observe$ method. Unlike observe$, intents are passed to a callback function rather than emitted from an Observable. Response(s) can be returned directly from the callback. It supports error propagation and request termination. Using this method over observe$ significantly reduces the code required to respond to requests.

For each intent received, the specified callback function is called. When used in request-response communication, the callback function can return the response either directly or in the form of a Promise or Observable. Returning a Promise allows the response to be computed asynchronously, and an Observable allows to return one or more responses, e.g., for streaming data. In either case, when the final response is produced, the handler terminates the communication, completing the requestor’s Observable. If the callback throws an error, or the returned Promise or Observable errors, the error is transported to the requestor, erroring the requestor’s Observable.

The platform provides a common mechanism to intercept messages or intents before their publication using interceptors.

An interceptor can reject or modify messages, allowing you to audit messages, or to perform schema validation to reject messages with an invalid payload. Multiple interceptors can be registered, forming a chain in which each interceptor is called one by one in registration order.

An interceptor must implement the intercept method of the MessageInterceptor for intercepting messages sent to a topic. Intercepting intents is similar, just implement IntentInterceptor instead. For each message or intent sent, the platform invokes the intercept method of the first registered interceptor, passing the message and the next handler as arguments. By calling the next handler in the intercept method, message dispatching is continued. If there is no more interceptor in the chain, the message is transported to the receivers, if any. But, if throwing an error in the intercept method, message dispatching is aborted, and the error transported back to the sender.

You register interceptors with the bean manager before starting the platform. Interceptors can be registered only in the host application. They are invoked in registration order.

The platform passes all messages to the interceptors, including platform messages vital for its operation. Interceptors must filter messages on their own, e.g. by topic, and let all other messages pass.

For message filtering, you can use the TopicMatcher, allowing you to test whether a topic matches a pattern. The pattern must be a topic, not a regular expression; thus, it must consist of one or more segments, each separated by a forward slash. The pattern can contain wildcard segments. Wildcard segments start with a colon (:), acting act as a placeholder for any segment value.

A typical use case for an interceptor is to perform schema validation to reject messages with an invalid payload.

The following code snippet illustrates how to implement an interceptor to validate the payload of messages. The interceptor expects a filter topic and JSON schema for its construction. The interceptor validates all messages that match the given filter topic against the given JSON schema.

As this interceptor requires a filter topic and JSON schema as its constructor arguments, we register it in the bean manager using a factory function, as shown below.

The Intention API enables controlled collaboration between micro applications. It is inspired by the Android platform where an application can start an activity via an Intent (such as sending an email).

To collaborate, an application must express an intention. An intention refers to one or more capabilities, or activity, in the Android platform. Capabilities can be browsed similar to a catalog and invoked by issuing an intent. Manifesting intentions enables us to see dependencies between applications down to the functional level.

Both capabilities and intentions need to be declared in the manifest. For example, capabilities can be browsed to create dynamic page content, such as a toolbar with items contributed via capabilities. When the user clicks an item of the toolbar, the application can issue an intent, which the platform transports to the application providing the capability.

The manifest is a special file that contains information about a micro application. A micro application declares its intentions and capabilities in its manifest file. The manifest needs to be registered in the host application via URL.

The following code snippet shows the manifest of the Product Catalog Application.

A capability can be thought of as an API that an application provides that can be invoked via intent, browsed via the DevTools or programmatically via the Intention API. Capabilities must be registered in the manifest or contributed programmatically via ManifestService.

A capability is formulated in an abstract way consisting of a type and optionally a qualifier. The type categorizes a capability in terms of its functional semantics (e.g., microfrontend if providing a microfrontend). Multiple capabilities can be of the same type. In addition to the type, a capability can define a qualifier to differentiate the different capabilities of the same type. A qualifier is a dictionary of arbitrary key-value pairs.

A capability can have private or public visibility. If private, which is by default, the capability is not visible to other micro applications; thus, it can only be invoked or browsed by the providing micro application.

A capability can specify parameters which the intent issuer can/must pass along with the intent. Parameters are part of the contract between the intent publisher and the capability provider. They do not affect the intent routing, unlike the qualifier.

Metadata can be associated with a capability in its properties section. For example, if providing a microfrontend, the URL to the microfrontend can be added as property, or if the capability contributes a toolbar item, its label to be displayed.

The following code snippet shows an example of how to declare a capability in the manifest of an application.

In addition to declaring a capability in the manifest, the micro application typically subscribes to intents in an activator. Refer to chapter Activator for more information.

The following code snippet shows an example of how an application can subscribe to intents.

For more information about handling an intent, see the chapter Receiving Intents in Intent-Based Messaging.

An intention refers to one or more capabilities that an application wants to interact with. Intentions are declared in the application’s manifest and are formulated in an abstract way, consisting of a type and optionally a qualifier. The qualifier is used to differentiate capabilities of the same type.

The following code snippet shows an example of how to declare an intention in the manifest of an application.

The intent is the message that a micro application sends to interact with functionality that is available in the form of a capability.

An intent consists of a type and optionally a qualifier, which are used by the platform to identify the capability(s) to which to transport the intent. A micro application can issue an intent only if having declared a respective intention in its manifest. Along with the intent, you can pass transfer data, either as payload, message headers or parameters. Passed data must be serializable with the Structured Clone Algorithm.

The following code snippet illustrates how to send an intent.

The following code snippet illustrates how to pass parameters with an intent. Passed parameters must be defined in the capability, otherwise the intent would be rejected.

In the following example, we use an authorization param to pass along the authorization token.

For more information about publishing an intent, see the chapter Publishing an Intent in Intent-Based Messaging.

A micro application can browse the catalog of capabilities using the ManifestService.

Looking up capabilities allows the flexible composition of web content, such as populating a toolbar with items provided in the form of capabilities. A micro application can look up its own capabilities and public capabilities for which it has declared an intention.

In below example, a toolbar is composed of toolbar items contributed by micro applications in the form of capabilities. When the user clicks a toolbar item, the integrating app issues an intent, which the platform then transports to the providing micro application.

The implementor of the toolbar can lookup toolbar item capabilities as follows:

By passing a ManifestObjectFilter to the lookupCapabilities$ method, you can control which capabilities to observe. Specified filter criteria are "AND"ed together. If not passing a filter, all capabilities visible to the requesting micro application are observed. When subscribing to the Observable, it emits the requested capabilities. The Observable never completes and emits continuously when fulfilling capabilities are registered or unregistered.

The platform allows you to browse and observe intentions. Unlike browsing capabilities, an application can browse the intentions of all micro applications. The use case for browsing intentions is somewhat technical, e.g., used by the DevTools to list intentions declared by micro applications.

You can browse intentions using the ManifestService.lookupIntentions$ method. By passing a ManifestObjectFilter to the lookupIntentions$ method, you can control which intentions to observe. Specified filter criteria are "AND"ed together. If not passing a filter, all intentions are observed. When subscribing to the Observable, it emits the requested intentions. The Observable never completes and emits continuously when matching intentions are registered or unregistered.

Capabilities can be declared statically via the manifest file or registered at runtime via the ManifestService. Registering or unregistering capabilities at runtime enables a micro application to contribute functionality more flexibly. For example, a micro application could inform the user about an upcoming maintenance window by temporarily registering a notification capability.

The following code snippet illustrates how to register a capability dynamically.

For an overview of the supported capability properties, see chapter Properties of Capability.

The host application, for example, can then observe these user-notification capabilities and display the message to the user.

For more information about how observing capabilities, see chapter Browsing Capabilities.

The platform allows registering or unregistering intentions at runtime. Note that this API is disabled by default.

To enable this API for a specific micro application, unset the flag intentionRegisterApiDisabled when registering the app.

Similar to registering a capability, you can register an intention using the ManifestService and its registerIntention method. For an overview of the supported intention properties, see chapter Properties of Intention.

The platform allows intercepting capabilities before they are registered, for example, to perform validation checks, add metadata, or change properties.

An interceptor must implement the intercept method of the CapabilityInterceptor interface. Interceptors are registered in the bean manager of the host application under the symbol CapabilityInterceptor as multi bean. Multiple interceptors can be registered, forming a chain in which each interceptor is called one by one in registration order.

The following interceptor assigns a stable identifier to each microfrontend capability.

The Router Outlet is a web component that allows embedding web content using the router.

Embedding web content using an iframe can quickly become a daunting task. For this reason, the SCION Microfrontend Platform provides a router outlet that solves many of the cumbersome quirks of iframes.

The router outlet is a web component that wraps an iframe. It can be used like a native HTML element. As its name suggests, the web content of the outlet is controlled by a router. The router is a platform service, allowing you to set the URL of an outlet from anywhere in the application, even across application boundaries. When adding the outlet to the DOM, the outlet displays the last URL routed for it, if any. When repeating routing for an outlet, its content is replaced.

The router outlet can be added to a HTML page as follows.

To display web content in the outlet, navigate to the URL using the router, as follows:

As an alternative to navigating directly to a URL, the router supports navigation to a microfrontend capability via an intent. For more information, refer to Navigating via Intent. Routing is explained in more detail in chapter Routing.

The host application typically adds one or more top-level router outlets to its main application shell.

Outlets can be nested, allowing a microfrontend to embed another microfrontend. There is no limit to the number of nested outlets. However, be aware that nested content is loaded cascaded, that is, only loaded once its parent content finished loading.

The following figure shows a microfrontend that embeds another microfrontend.

The router outlet can adapt its size to the preferred size of its embedded content. The preferred size is set by the microfrontend embedded in the router outlet, which, therefore, requires the embedded microfrontend to be connected to the platform. For detailed instructions on how to register a micro application and connect to the plaform, refer to the chapter Configuration and Startup.

Embedded content can report its preferred size using the PreferredSizeService, causing the outlet to change its size.

In addition to explicitly setting the preferred size, the platform provides a convenience API to bind a DOM element via PreferredSizeService.fromDimension to automatically report its content size as preferred size to the outlet.

Prerequisites for the element used as outlet size provider:

By default, page scrolling is enabled for the embedded content, displaying a scrollbar when it overflows. If disabled, overflowing content is clipped, unless the embedded content uses a viewport, or reports its preferred size to the outlet.

The below code snippet illustrates how to disable page scrolling for the embedded content.

The router outlet allows the registration of keystrokes, instructing embedded content at any nesting level to propagate corresponding keyboard events to this outlet.

The outlet dispatches keyboard events for registered keystrokes as synthetic, untrusted keyboard events via its event dispatcher. They bubble up the DOM tree like regular events. Propagated events are of the original type, meaning that when the user presses a key on the keyboard, a keydown keyboard event is dispatched, or a keyup event when releasing a key, respectively.

A keystroke has the following syntax.

A keystroke is a string that has several parts, each separated with a dot. The first part specifies the event type (keydown or keyup), followed by optional modifier part(s) (alt, shift, control, meta, or a combination thereof) and with the keyboard key as the last part. The key is a case-insensitive value of the KeyboardEvent.key property. Two keys are an exception to the value of the KeyboardEvent.key property: dot and space.

The keystroke behavior can be controlled via flags, a dictionary of key-value pairs. Flags are optional. Multiple flags are separated by a semicolon. The following flags are supported:

You can register keystrokes on a <sci-router-outlet> as follows. Multiple keystrokes are separated with a comma.

Alternatively, you can register keystrokes on the DOM element as shown below.

The router outlet emits the following events as custom DOM events. You can attach an event listener declaratively in the HTML template using the onevent handler syntax, or programmatically using the addEventListener method.

The following example attaches an event listener in the HTML template.

For an Angular application, it would look as follows:

The example below adds an event listener programmatically.

The router outlet allows associating contextual data, which then is available to embedded content at any nesting level. Data must be serializable with the structured clone algorithm. Embedded content can look up contextual data using the ContextService. Typically, contextual data is used to provide microfrontends with information about their embedding environment.

Each outlet spans a new context. A context is like a Map with key-value entries. Contexts form a hierarchical tree structure. When looking up a value and if the value is not found in the current context, the lookup is retried on the parent context, repeating until either a value is found, or the root of the context tree has been reached.

Imagine a tabbar with tabs implemented as a microfrontend. As an example, a microfrontend should highlight its tab in the tabbar when its data changes. For each tab, you can define a random highlighting topic and put it to the context of the tab router outlet. The microfrontend can then send an event to that topic when its data changes.

Embedded microfrontend can then read the highlighting-topic from the current context and send an event to that topic when its data changes.

Loading and bootstrapping a microfrontend can take some time, at worst, only displaying content once initialized. To indicate the loading of a microfrontend, the navigator can instruct the router outlet to display a splash until the microfrontend signals readiness.

The splash is the markup between the opening and closing tags of the router outlet element.

The splash is displayed until the embedded microfrontend signals readiness.

To lay out the content of the splash use the pseudo-element selector ::part(splash).

Example of centering splash content in a CSS grid container:

You can find the full list of available properties and methods of SciRouterOutletElement in the TypeDoc.

Routing refers to the navigation in a router outlet using the router of the SCION Microfrontend Platform.

In SCION Microfrontend Platform, routing means instructing a <sci-router-outlet> to display the content of a URL. Routing works across microfrontend and micro application boundaries, allowing the URL of an outlet to be set from anywhere in the application. The web content displayed in an outlet can be any HTML document that has not set the HTTP header X-Frame-Options. Routing is also referred to as navigating.

The router supports multiple outlets in the same application to co-exist. By giving an outlet a name, you can reference it as the routing target. If not naming an outlet, its name defaults to primary. If multiple outlets have the same name, they all show the same content. If routing in the context of a router outlet, that is inside a microfrontend, and not specifying a routing target, the content of the current outlet is replaced.

An outlet does not necessarily have to exist at the time of routing. When adding the outlet to the DOM, the outlet displays the last URL routed for it. When repeating routing for an outlet, its content is replaced.

A router outlet is defined as follows. If no navigation has been performed for the outlet yet, then its content is empty.

The router supports navigating via URL or intent as described below.

The URL of the page to be loaded into the router outlet is passed to the router, as follows:

The router allows to use both absolute and relative paths. A relative path begins with a navigational symbol /, ./, or ../. By default, relative navigation is relative to the current window location of the navigating application, unless specifying a base path for the navigation.

The URL being passed to the router can contain named parameters which the router replaces with values of the passed params object. A named parameter begins with a colon (:) and is allowed in path segments, query parameters, matrix parameters and the fragment part, e.g., product/:id or product;id=:id or products?id=:id.

As an alternative to navigating directly to a URL, the router supports navigation to a microfrontend capability via an intent. We refer to this as intent-based routing.

We recommend using intent-based routing over url-based routing, especially for cross-application navigations, since the navigation flows are explicit, i.e., declared in the manifest, and to keep the microfrontend URLs an implementation detail of the micro applications that provide the microfrontends.

The following code snippet illustrates how to display the product microfrontend in the aside outlet. Note that you only need to pass the qualifier of the microfrontend capability and not its type. The capability type, which is always microfrontend, is implicitly set by the router.

Applications can provide microfrontend capabilities through their manifest. A microfrontend can be either application private or exposed to other micro applications. The platform requires all microfrontend capabilities to be of type microfrontend. A particular microfrontend can be identified using its qualifier.

The microfrontend capability can also declare a preferred target outlet, as follows:

When navigating via intent, the target outlet is resolved as follows:

Persistent navigation refers to the mechanism for restoring the navigational state after an application reload.

The router does not provide an implementation for persistent navigation out-of-the-box, mostly because many persistence strategies are imaginable. For example, the navigational state could be added to the top-level URL, stored in local storage, or persisted in the backend.

However, you can easily implement persistent navigation yourself. The router publishes navigations to the topic sci-router-outlets/:outlet/url; thus, they can be captured and persisted. When starting the application, you can then replay persisted navigations using the router.

For illustrative purposes, the following code snippet shows how to capture and persist navigations.

When starting the application, you can replay persisted navigations as following.

To unload an outlet’s content, use null as the URL when routing, as follows:

Routing does not add an entry to the browsing history, and, by default, not push a navigational state to the browser’s session history stack.

You can instruct the router to add a navigational state to the browser’s session history stack, allowing the user to use the back button of the browser to navigate back in an outlet.

The lifecycle of the SCION Microfrontend Platform is controlled by the class MicrofrontendPlatform, providing methods to start and stop the platform. During its lifecycle, it traverses different lifecycle states, as defined in the enumeration PlatformState.

You can register a listener that is called when the platform enters a state, as follows:

Alternatively, a bean can implement the PreDestroy lifecycle hook to get notified when the platform is about to stop, as follows:

During the transition from the Starting to the Started platform state, the platform cycles through different runlevels for running initializers, enabling the controlled initialization of platform services. A runlevel is represented by a number greater than or equal to 0. Initializers can specify a runlevel in which to execute. Initializers bound to lower runlevels execute before initializers of higher runlevels. Initializers of the same runlevel may execute in parallel. The platform enters the state Started after all initializers have completed.

The platform defines the runlevels 0 to 3, as follows:

To hook into the platform’s startup process, you can register an initializer and bind it to a runlevel. You are not limited to the runlevels 0 to 3. For example, to run an initializer after all other initializers have completed, register the initializer in runlevel 4 or higher.

The following code snippet illustrates how to register an initializer in runlevel 4:

Starting the host may take some time. During startup, the manifests of the registered applications are fetched, activator microfrontends are installed, and the platform waits until all applications have signaled readiness.

You can monitor the startup progress and provide feedback to the user like displaying a progress bar or a spinner. The platform reports the progress as a percentage number.

The following code snippet illustrates how to monitor the startup progress:

The platform tracks the progress of following activities:

When the platform is stopped, it first enters the Stopping platform state. In this state, the beans registered with the platform are destroyed. Beans are destroyed according to their destruction order as specified at bean registration. Beans of the same destroy order are destroyed in reverse construction order. Beans can implement the PreDestroy lifecycle hook to get notified when they are about to be destroyed.

The platform allows the application to send messages while the platform is stopping. After all beans are destroyed, the client is disconnected from the host and the platform enters the Stopped state.

By default, the platform initiates shutdown when the browser unloads the document, i.e., when beforeunload is triggered. The main reason for beforeunload instead of unload is to avoid posting messages to disposed windows. However, if beforeunload is not triggered, e.g., when an iframe is removed, we fall back to unload.

You can change this behavior by registering a custom MicrofrontendPlatformStopper bean, as follows:

The focus monitor can be used to observe whether the current microfrontend has received focus or contains embedded web content that has received focus.

The router outlet <sci-router-outlet> fires a focuswithin custom DOM event when the microfrontend loaded into the outlet, or any of its child microfrontends, has gained or lost focus. It contains the current focus-within state in its details property as a boolean value: true if focus was gained, or false if focus was lost.

For an Angular application, it would look as follows:

The event does not bubble up through the DOM. After gaining focus, the event is not triggered again until embedded content loses focus completely, i.e., when focus does not remain in the embedded content at any nesting level. This event behaves like the :focus-within CSS pseudo-class but operates across iframe boundaries. For example, it can be useful when implementing overlays that close upon focus loss.