Support for Multiple Application Scopes (Agents) within a single window process

[Davidhanson90]

Enhancement Request

This enhancement is looking at the problem from a web perspective but could be extended to other implementing technologies.

Use Case:

As more web applications adopt micro-frontend architecture, users often encounter scenarios where multiple application contexts need to be loaded into a single window process through dynamic code resolution techniques like module federation. Currently, the FDC spec assumes a one-to-one mapping between Window, Agent, and Application, which limits the ability to handle multiple application contexts within a single window. This creates challenges for users who need to interact with different application scopes seamlessly within the same window environment.

Workflow Description

The proposed enhancement involves updating the FDC spec to support the creation of Agents with different application scopes within a single window process. This would allow multiple micro-frontends applications to coexist and interact within the same window, providing a more flexible and efficient user experience. The workflow should enable dynamic resolution and management of multiple Agents, each corresponding to different applications, within a single window context.

Workflow Examples

Multi-tool Dashboard

• A user accesses a dashboard that integrates multiple tools (e.g., a calendar, email client, and task manager) using micro-frontend architecture.
• Each tool operates as a separate application deployed remotely from the container however will share the context within the same window.
• The enhanced FDC spec allows each tool to create and manage its own Agent within the same window, enabling seamless interaction and communication between the tools.

Additional Information

Supporting the creation of Agents with different application scopes within a single window process would significantly enhance the flexibility and usability of applications using micro-frontend architecture. This enhancement would reduce the need for redundant window processes, streamline resource management, and improve the overall user experience by enabling more dynamic and integrated interactions between multiple application contexts.

[kriswest]

Many thanks for raising the issue @Davidhanson90.

There is a proposal to resolve this use case (in both Electron-style containers and on the web) in the FDC3 for Web Browsers proposal:
https://tick42-my.sharepoint.com/:w:/g/personal/finsemble_datastore_interop_io/EZ0dfTCdRlJCnIF3C_1Oit0BF3fsXyvlMbisXp722DC9Kg?e=dRVqQm
(under the heading 'Sub-application API Proposal (use case 4)').

To give a basic overview, it proposes that the following function is added to the FDC3 API:

/**	 
 * @param {string} params Required parameters object, which must include  
 * at least a fully qualified appId or appD URL for the application to 
 * indicate the app's identity. 
 * @param {string} params.appId The fully qualified appId 
 * (in the form appid@<appd origin> for the application 
 * @param {URL} params.appDUrl The URL to the appD record providing the  
 * app's identity, used as an alternative to a fully qualified appId. 
 *  
 * @return A promise that resolves to a DesktopAgent implementation or  
 * rejects if the app identity could not be validated. 
 */ 

type getSubAgent = ( 
    params: GetSubAgentParams,  
): Promise<DesktopAgent>  

type GetSubAgentParams = { 
  appId?: string, 
  appDUrl?: URL 
} 

and that the window acquires a copy of the API as if it were itself an application, perhaps making it available globally at window.fdc3 if not already present, then the sub-applications call this function to identify themselves with details of an appD record (which might express intents that it can resolve) and then retrieve their own copy.

Please feel free to comment on the proposal or to propose changes - it hasn't had as much attention as the other parts of the proposal, although it builds on some of the same approaches (for example the need for additional identity validation steps).

[Davidhanson90]

Ok thanks for this, it does indeed look like the solution to the problem stated.

[bingenito]

I very much want to also bring this into fdc3-dotnet as I feel it will solve alot of problems with native apps built through composition to address appid/instance at the module or widget level.

[robmoffat]

If I'm reading this right, we're basically saying that one application can exist in multiple windows?

What are the implications for delivering intents or broadcast contexts?

[kriswest]

If I'm reading this right, we're basically saying that one application can exist in multiple windows?

@robmoffat No, multiple applications in the same window and allowing them to communicate with each other over FDC3 in the same way as they would with apps running in other windows.