Receives an intent when some micro application wants to collaborate with this micro application.
Intents are typically handled in an activator. Refer to Activator for more information.
The micro application receives only intents for which it provides a fulfilling capability through its manifest. You can filter received intents by passing a selector. The selector supports the use of wildcards.
If the received intent has the MessageHeaders.ReplyTo header field set, the publisher expects the receiver to send one or more replies to that ReplyTo topic. If streaming responses, you can use the takeUntilUnsubscribe operator to stop replying when the requestor unsubscribes.
const selector: IntentSelector = {
type: 'auth',
qualifier: {entity: 'user-access-token'},
};
Beans.get(IntentClient).observe$(selector).subscribe((request: IntentMessage) => {
const replyTo = request.headers.get(MessageHeaders.ReplyTo);
authService.userAccessToken$
.pipe(takeUntilUnsubscribe(replyTo))
.subscribe(token => {
Beans.get(MessageClient).publish(replyTo, token);
});
});
Allows filtering intents. The qualifier allows using wildcards (such as * or ?) to match multiple intents simultaneously.
*):**{'*': '*'}.null or undefined values).?):**An Observable that emits intents for which this application provides a satisfying capability. It never completes.
Convenience API for handling intents.
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.
Allows filtering intents. For more information, see the API description of observe$.
Specifies the callback to be called for each intent. When used in request-response communication, the callback function can return the response either directly or in the form of a Promise or Observable. If returning a response in fire-and-forget communication, it is ignored. Throwing an error in the callback does not unregister the callback.
Subscription to unregister the callback. Calling {@link Subscription.unsubscribe} will complete the Observable of all requestors, if any.
Issues an intent.
A micro application can issue intents for intentions declared in its manifest. The platform transports the intent to micro applications that provide a fulfilling capability. 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.
A micro application is implicitly qualified to interact with capabilities that it provides; thus, it must not declare an intention.
Describes the intent. The qualifier, if any, must be exact, thus not contain wildcards.
Specifies optional transfer data to be carried along with the intent. It can be any object which is serializable with the structured clone algorithm.
Controls how to issue the intent and allows setting message headers.
A Promise that resolves when dispatched the intent, or that rejects if the intent could not be dispatched, e.g., if missing the intention declaration, or because no application is registered to handle the intent.
Issues an intent and receives one or more replies.
A micro application can issue intents for intentions declared in its manifest. The platform transports the intent to micro applications that provide a fulfilling capability. 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.
A micro application is implicitly qualified to interact with capabilities that it provides; thus, it must not declare an intention.
Describes the intent. The qualifier, if any, must be exact, thus not contain wildcards.
Specifies optional transfer data to be carried along with the intent. It can be any object which is serializable with the structured clone algorithm.
Controls how to send the request and allows setting request headers.
An Observable that emits when receiving a reply. It never completes unless the intent handler sets the status code ResponseStatusCodes.TERMINAL in the MessageHeaders.Status message header. Then, the Observable completes immediately after emitted the reply. The Observable errors if the intent could not be dispatched or if no replier is currently available to handle the intent. It will also error if the intent handler sets a status code greater than or equal to 400, e.g., ResponseStatusCodes.ERROR.
Generated using TypeDoc
Allows sending and receiving intents between microfrontends across origins. This client is part of the Intention API of the SCION Microfrontend Platform.
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).
Like topic-based communication, intent-based communication implements the pub/sub (publish/subscribe) messaging pattern, but is, in contrast, more restrictive when sending messages. Sending messages is also referred to as issuing intents. It requires the sending application to declare an intention in its manifest. Intents can only be issued if there is at least one fulfilling capability present in the platform to handle the intent. The platform transports intents exclusively to micro applications that provide a fulfilling capability via their manifest.
The communication is built on top of the native
postMessagemechanism. The host app acts as message broker.Intent Addressing
In intent-based communication, 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.
Request-Response Messaging
Sometimes it is useful to initiate a request-response communication to wait for a response. Unlike with fire-and-forget intents, a temporary inbox is created for the intent issuer to receive replies.
IntentMessage
Intent
MessageHeaders