Hi! Our company uses an API Endpoint Discovery. It registers available endpoints within the mesh and allows consumers to subscribe to endpoints without actually having the need to know what service implements them or how they are reached (URI). A question that came up was how that possibly translates to the provider name the consumer has to write into a contract. We thought about putting the endpoint itself there. Are some of you using a similar setup and want to share experience? Kind regards, Werner

The crux is that in our mesh the consumer never really knows the NAME of the service that implements the endpoints/resource it calls. It can differ per environment and per region depending on the deployment topology. Therefore, using a specific service name for the provider is problematic. Can we use something else like tags filled with endpoints?

How would you characterise the groups of functionality across all the disparate endpoints? Are there cohesive collections of endpoints that are usually implemented together?

Those endpoints are typically grouped per API in an API document. In the past there was no real governance on the coarseness of an API Document. Now we are indeed steering on having a single API Document per Bounded Context, but that is not a hard requirement. We had the idea to use the name of the API (Document) as the provider name. (Moving an endpoint to a different API is done very rarely in to meet some requirements.)

yep!

Awesome, we’ll pilot this