Client integration with Service Discovery

[ptrdom]

I was thinking about how to integrate service discovery in endpoints4s clients. Typically they work by either fetching service URL together with a service call and maybe caching the lookup result for some time, or it could be done off the main service call path. From the looks of it, endpoints4s does not provide a clean way to integrate with it - EndpointsSettings are a def, but lookup calls will typically require and async interaction, so effect monads need to be exposed, like () => Future[EndpointSettings] or better yet EndpointSettings(baseUri: () => Future[String], ...). I know I can just override algebra, but maybe endpoints4s could provide a first-class support for service discovery. Thoughts?

[ptrdom]

I guess having an effectful client provider is also a way to go, but still a question about first-class support in endpoint4s remains.

[ptrdom]

Or we could just add a new value to EndpointSettings, which would be used for resolution instead of baseUri if provided. That would take care of backwards compatibility.

[julienrf]

Thank you for raising this discussion. I think there are several scenarios here and I am not sure how to support them all in endpoints4s.

• we could query a service registry once and get a baseUri that would be used by subsequent calls (that’s the easiest to implement outside of endpoints4s)
• we could imagine going through the service registry more often, e.g. after every unexpected failed call, or after some delay (in case more instances are added dynamically), or having an explicit mechanism to invalidate the known baseUri.

If there is a strong need to support the more “dynamic” scenarios, then we should take some time to design the right level of support in endpoints4s.

[ptrdom]

Feels like adding a EndpointSettings parameter baseUrlLookup: () => Future[String] would open up most capabilities with the least effort. You can do resolution each call or caching then. Failed call checks are more involved.