Add support for API consumer information as artifact metadata

[simonnepomuk]

Feature Description

In my work environments I often face the problem of not knowing which service depends on which API. This then leads to making rounds with development teams or scrolling through outdated confluence documentation. It would be nice to have one central place where I can look up dependencies between the services, so I can know how big of an impact breaking changes would have.

Proposed Solution

Add a list of consumers as a field on the metadata of an artifact. APIs and dependencies can then be managed in a central place.

Additional Context

This could also be integrated nicely in an automated workflow with the maven plugin. E.g. when pulling an artifact with the maven plugin, you can pass the option to add the pulling application as a consumer to the artifact metadata.

[EricWittmann]

Thanks for opening the issue. This sort of functionality has been discussed. Most likely we would implement it as a new artifact type (or maybe even a new entity type) that could reference multiple artifacts. Perhaps an Application type that is managed as a separate collection in the REST API. The application could reference multiple schemas.

[simonnepomuk]

Thanks for responding so quickly and sorry for the long delay. You're right, probably introducing a new entity is the best approach to handle this (and other related) use-cases.

The main concern I have with this functionality is implementing it in a way that makes modelling the producer/consumer relations implicit. In my opinion, this should happen automatically (i.e. when requesting a schema in your CI pipeline). I fear that making developers/architects having to explicitly model the relations, would result in the same outdated information as often is the case in architectural diagrams or other types of documentation that needs to kept up date manually.

I would assume this isn't a high priority issue before the 3.0 release but if I can be of assistance in the meantime (like drafting a initial design), I'd be happy to help when I find the time. Please let me know what you think :)

[simonnepomuk]

@EricWittmann I thought a bit about this and did a bit of research on tooling surrounding this problem and it looks like Backstage would be the correct tool for the job. Maybe it would make sense to have a separation of concerns and put service management out of scope for the registry and instead write a plugin for backstage so they are tightly integrated.

What do you think?