URLS flowing to service discovery

[glennc]

Several times now I have either wanted to consume a resource that I had a URL for OR run a container that I would communicate with via a URL. Therefore I wanted to model both these in the AppHost and then use Service Discovery in another part of my application.

In my mind the first of these is something like the AddConnectionString method we have, something like this:

Where the ollama url would be a parameter that needs to be filled in during deployment somehow, i.e. we wouldn't do anything to try and make it work you would have to provide it.

For the second one the code I wrote naturally without thinking looked like this:

In both these cases I had code in the backend that would communicate with the endpoint of both using HTTPClient either directly or because their SDK would accept a HTTPClient that I would resolve from DI.

[mitchdenny]

With containers you can do this:

.WithReference(vectordb.GetEndpoint("http"))

With regards to having something like AddUrl(...) ... I think we tried something like that and in the end I don't think it ended up being that compelling vs. just using an environment variable/connection string. It isn't something that is dynamically allocated at deployment time (like an ACA hosted endpoint).

[glennc]

Sure, but it is configuration that must be used during development and known about during deployment. So by not modelling it you are creating a piece of dependency information that you cannot reason about in deployment tooling. I would want an ability for an interactive deployment experience like azd to prompt me or for something that is generating deployment artifacts to know that this information is required.

I also want to name the service that I am calling on and have that work with service discovery as I would in the sample code, allowing me consistent HTTPClient usage rather than pulling a URL out of config for just this instance.

[davidfowl]

Putting this in 8.1. I think it's reasonable to have a concrete overload of WithReference that takes a container resource and has this behavior. We didn't want to enable this by default on the base resource because our containers are mostly connection string based, but we can avoid the ambiguous interface problem with more overloads.

[mitchdenny]

Didn't we try this and ultimately run into ambiguity problems?

[davidfowl]

Yes I think you're right.

[glennc]

I am interested in the ambiguity as I don't know what you hit before. Had parameters been designed last time? since I think this is that with some bells on.

Something else that may be a completely different feature. A thing I am working on at the moment has multiple projects that call into the same external API, and therefore need to be configured with the same bearer token to allow access to that API. Right now I am using user secrets and environment variables in the AppHost to avoid duplication on each project. These two things seem related if I was to model the URL for the external API the way I described here then I would also want to configure the token here and say that it is a bearer token that needs to be set when creating a client for this URL.

I thought it was worth throwing this in for consideration as we looked at it. Not sure we have to solve it.