Implement `IResourceWithEndpoints` instead of `IResourceWithConnectionString`

[brendonparker]

Wondering why you went with IResourceWithConnectionString (for databases) over IResourceWithEndpoints?

Ask

It'd be nice if I could do something like:

var localStack = builder.AddLocalStack();
 
var api = builder
    .AddProject<MyApi>("api")
    .WithExternalHttpEndpoints()
    .WithEnvironment("AWS_ENDPOINT_URL_SQS", localStack.GetEndpoint("http"));

Reasoning

I'd like to not need to bring in all the localstack client dependencies into my application. For something simple, like just using SQS, the AWS_ENDPOINT_URL_SQS should do the trick and get picked up by the native AWS SDK for .NET.

Notes

Standard Interfaces

Thank you!

[Blind-Striker]

Well, it's a good question 🙃 and honestly, when I first started learning Aspire, almost every example I came across used IResourceWithConnectionString. At the time, it felt a bit weird to use that for non-database resources, but I guess I never thought to dig deeper. If I’d known about IResourceWithEndpoints back then, I probably would’ve gone with that instead 😅

I’ll need to look into this a bit more to see if switching would introduce any breaking changes or affect where endpoints get assigned within Aspire’s lifecycle. Internally, there’s quite a bit of logic built around connection string, the whole LocalStack autowiring currently depends on that.

Either way, I’ll follow up before the next release cycle with a proper answer or plan.

Also, just to clarify, you don’t have to use the LocalStack client library, similar method should work with connection string as well (probably).

Thanks again for raising this, it’s a really good point and definitely worth exploring further! 🙏

[brendonparker]

Totally understand how you could go down that path and not question it. Also, as quickly as aspire surfaced and iterated, it would be easy to miss.

similar method should work with connection string as well (probably).
I was just trying to avoid needing to change the application-level code at all. Ideally, for me, all the "hacky" stuff happens in the aspire orchestration and the app-code goes unchanged as possible.

I'm still trying to wrap my head around the Aspire APIs. I was able to do this as a workaround:

var api = builder
    .AddProject<MyApi>("api")
    .WithExternalHttpEndpoints()
    .WithEnvironment("AWS_ENDPOINT_URL_SQS", localStack.Resource.ConnectionStringExpression);

So I don't need this feature. But still seems sensible to add.