Support deep-linking to child resources in CosmosDB, EventHubs, ServiceBus

[eerhardt]

The next step after EventHubs, ServiceBus, and CosmosDB Hosting integrations should create Resources for children (dotnet/aspire#7407) is that we should support "deep linking" to the child resources and have corresponding client integration APIs for adding the child directly.

For example, in CosmosDB:

AppHost

var cosmos = builder.AddAzureCosmosDB("cosmos")
                .RunAsPreviewEmulator(e => e.WithDataExplorer());

var db = cosmos.AddCosmosDatabase("db");
var entries = db.AddContainer("entries", "/id");

builder.AddProject<Projects.CosmosEndToEnd_ApiService>("api")
       .WithExternalHttpEndpoints()
       .WithReference(cosmos) // adds 'cosmos' connection string pointing to root service
       .WithReference(db) // adds 'db' connection string pointing to the root service + ";Database=db"
       .WithReference(entries); // adds 'entries' connection string pointing to the root service + ";Database=db" + ";Container=entries"

Then on the app side, we should have corresponding APIs for directly referencing these children:

builder.AddAzureCosmosClient("cosmos"); // exists today
builder.AddAzureCosmosDatabaseClient("db"); // new, registers a Microsoft.Azure.Cosmos.Database in DI
builder.AddAzureCosmosContainerClient("entries"); // new, registers a Microsoft.Azure.Cosmos.Container in DI

On CosmosDB EF, this will simply the existing code:

builder.AddCosmosDbContext<TestCosmosContext>("cosmos", "db"); // today
builder.AddCosmosDbContext<TestCosmosContext>("db"); // new - gets all connection information from the 'db' connection string

QUESTION: What happens if you AddCosmosDbContext to a "container"? Today AFAIK EF defaults to using the DbContext TypeName as the container name. Maybe we can change that to the specified container if you deep-link to that container.

We should do similar APIs for EventHubs and ServiceBus as well, where it makes sense.

We should also remember to update the Azure Functions config support as well.

Resource Types Requiring Support

• CosmosDB
• Service Bus
• EventHubs
• Azure Storage
• OpenAI Configure OpenAI models in the app host #6577
• Azure WebPubSub Hub

[eerhardt]

The other child resources in Azure are:

• Storage (works today)
• OpenAI - will be done in Configure OpenAI models in the app host #6577
• WebPubSub

So maybe we need to think about WebPubSub here as well. Today we have:

aspire/playground/webpubsub/WebPubSub.AppHost/Program.cs

Lines 5 to 13 in 172ec29

	var web = builder.AddProject<Projects.WebPubSubWeb>("webfrontend")
	.WithExternalHttpEndpoints()
	.WithReference(wps);
	// Now only works in production since localhost is not accessible from Azure
	if (builder.ExecutionContext.IsPublishMode)
	{
	wps.AddHub("ChatForAspire").AddEventHandler($"{web.GetEndpoint("https")}/eventhandler/", systemEvents: ["connected"]);
	}

aspire/playground/webpubsub/WebPubSubWeb/Program.cs

Line 5 in 172ec29

builder.AddKeyedAzureWebPubSubServiceClient("wps1", Constants.ChatHubName);

This can be simplified as well to only need to pass 1 connection name, and not the HubName.

[captainsafia]

@eerhardt I upated the issue description with a list of the resource types that have a parent-child concept for us to support here. Let me know if I missed any.

WRT to WebPubSub Hub (lol), it seems like AddKeyedAzureWebPubSubServiceClient currently assumes tha that service key is the hub name. Do we want to create a non-keyed overload as well that will set the default hub name without registering a keyed service or do we always want to map child resources to keyed services in this case?

[eerhardt]

I upated the issue description with a list of the resource types that have a parent-child concept for us to support here

That list looks good. Thanks.

Note that for OpenAI - Configure OpenAI models in the app host (dotnet/aspire#6577) has started for this. I plan on finishing that PR off in 9.2, so you shouldn't have to worry about that one.

WRT to WebPubSub Hub

@vicancy - can you answer this question?

[vicancy]

WRT to WebPubSub Hub (lol), it seems like AddKeyedAzureWebPubSubServiceClient currently assumes tha that service key is the hub name. Do we want to create a non-keyed overload as well that will set the default hub name without registering a keyed service or do we always want to map child resources to keyed services in this case?

Currently for AddKeyedAzureWebPubSubServiceClient, HubName is set to the service key if it is not set through Action<AzureMessagingWebPubSubSettings>? configureSettings. There is also a public method AddAzureWebPubSubServiceClient which expects HubName to be set through Action<AzureMessagingWebPubSubSettings>? configureSettings and registers a default service.

aspire/src/Components/Aspire.Azure.Messaging.WebPubSub/AspireWebPubSubExtensions.cs

Lines 33 to 38 in 02d2e66

	public static void AddAzureWebPubSubServiceClient(
	this IHostApplicationBuilder builder,
	string connectionName,
	Action<AzureMessagingWebPubSubSettings>? configureSettings = null,
	Action<IAzureClientBuilder<WebPubSubServiceClient, WebPubSubServiceClientOptions>>? configureClientBuilder = null)
	{

wps.AddAzureWebPubSubServiceClient("hub1", setting=>setting.HubName = "HubName1");

I love the idea, for Web PubSub, we could have:

in app host:

var hub = builder.AddWebPubSub("wps1").AddHub("hub1", "HubName1");
var web = builder.AddProject<Projects.WebPubSubWeb>("webfrontend") 
     .WithExternalHttpEndpoints() 
     .WithReference(hub); 

on web app side, we could figure out that the resource is a hub resource, we automatically set the HubName as what is defined in app host, as "HubName1"

build.AddAzureWebPubSubServiceClient("hub1")

[davidfowl]

We're missing azure storage from this list.

[captainsafia]

@davidfowl lol it's item number 4

We already have a child resource model for Storage given the different client integration packages and the fact that the Add APIs on the hosting side already return ResourceBuilder's that you can WithReference.

[davidfowl]

We're missing blob containers.