catalog model: support additional System relations

Feature Suggestion

I would like support for additional relations on the System entity.

Possible Implementation

On the System entity there could be a spec.consumesApis or spec.dependsOn relation defined explicitly.

Alternatively, a visibility could be declared on an API entity and then we wouldn’t have to declare the system then we could derive the public APIs from the sub-components that are part of the system. This would mean that all API relations would be inferred through a component.

Context

The docs say

With increasing complexity in software, systems form an important abstraction level to help us reason about software ecosystems.

Part of understanding those systems is understanding its boundaries. That is covered in part by an API that is part of a system but a critical part of that is surfacing the APIs that system depends on.

[martina-if]

Bump! I’d love to see this rollup feature as well. It can make the graphs even more useful because you can explore the architecture diagram in “layers” going from high level to deeper details. We have a couple of adopters asking for this 😁

[jcarres-mdsol]

I’m going to leave here a comment carried over from https://github.com/backstage/backstage/issues/9014

To me the most natural behavior for system is to roll up the information from the components in the system.

According to Backstage docs, A system, in this sense, is a collection of resources and components that exposes one or several public APIs. And unless we want to re-declare APIs, those are going to be defined already in lower level components. So to keep single source of truth we should be able to expose them. Additionally we may want to consider the behavior of providesApi/apiProvidedBy does it override or does it augment, etc. But I think an MVP is the rollup behavior, then further extensions can be designed and implemented later as use-cases emerge.