Allow an AppD application record to reference other apps that are *required* for it to run

[kriswest]

Enhancement Request

Allow an AppD application record to reference other apps that are required to enable or support it.

• add an optional required-applications element to the appD application record schema
• required-applications should be an array of required appIds from the same appD, or fully-qualified appIds (add @domain.of-appd.com) if referencing another appD
• links should be considered uni-directional as a required application might not need an app that requires it.

Use Case:

Although FDC3 enables dynamic links between apps through channels and intents, there are situations where another app is required for the application to work. For example:

• a set of user interface apps might depend on a service application to own a websocket connection and supply them with data
• a 'create order' application (essentially a micro-frontend comprised of a single data entry form) might rely on a service application or larger UI application to actually create an order once it has collected the data.

Although many FDC3 Desktop Agents will plug directly into an AppD, making all the contained apps available, there are administrative situations where an appD record needs to be 'installed' or 'imported' (copied from an external appD to an internal one) or an 'entitlement' configured within a single appD (authentication can be used to filter applications returned from an appD by the user role). In these situations, the dependency relationships that required-applications would document enable the implementation of these management functions, without the admin needing to know these relationships independently.

Although this issue proposes a simple list of appIds for required-applications, it could be extended to express further requirements such as the required apps needing to be already running/launched automatically when an app that depends on them is started. This wouldn't be needed where they can be started via a raised intent, but might be for integrations involving channels.

Additional Information

Note: the Web Application manifest contains a similar related-applications member (currently at risk), which serves a different use-case: linking to other other implementations or versions of the same application (for example a native mobile app version of a web app). However, this issue has drawn inspiration from it.

[kriswest]

Notes from #802:

• Discussed use cases for both 'required' apps and 'related' apps in appD config
  • E.g. a micro-frontend related to a larger application, such as a 'CreateOrder' form and an OMS, might express a required relationship for the form to the OMS and a related (optional) relationship for the OMS to the form.
  • Some participants felt that this could also be handled through a 'grouping' field, although it was observed that this loses some of the nuances of teh relationship
  • Some participants expressed concerns that we might be wandering into NPM style dependency relationships.
  • @kriswest argued that such relationships would be far more limited and this metadata is only intended to allow a UI to implement a 'guard rail', rather than any form of hard contract.
  • It was also suggested that this could be achieved via existing interop data (show a warning that no other app is listening for or can raise an intent specified in the apps interop config
    • @kriswest it is not required that there exist an app to raise or resolve an intent that another app supports, so I believe this is outside the use-case for that configuration.
• The end of the meeting curtailed discussion, however, it was agreed to table this issue for the time being but to leave it open to revisit later.