Aspire Component 🚀

[mumby0168]

We'd love to look into making a .NET Aspire component based on this package and there are a couple of things we'd like to tackle and a couple of aims of a re-write, these are listed below, but we'd love for you to add some more requests onto this issue via the comments.

Checkout the branch so far and feel free to provide some feedback.

• .NET Aspire - Branch

Essentials 🛒

• NO BREAKING CHANGE to the existing data format, if you have used the package before your data stored in cosmos DB should work with the new API
• Use System.Text.Json serializers by default
• Expose the CosmosClient to allow people to re-use the configured instance where required
• Health checks based on the item types configured to be used by the library, including (databases, and containers)
• Documentation first, write the docs as we go 📃

Feedback 🙏

• What would you like to see?
• What did you really like about the old interface?
• What do you think could be improved on the new interface?

[peteraritchie]

Looks great so far!

Will this be springboarding off of existing Aspire CosmosDB support with regards to orchestration? For example, would AppHost.Program contain code similar to:

var cosmosdb = builder.AddAzureCosmosDB("cdb")
    .AddDatabase("cosmosdb");
IResourceBuilder<ProjectResource> apiService = builder
    .AddProject<Projects.AspireSample_ApiService>("apiservice")
    .WithReference(cosmosdb);

What help, if any, could you use?

[IEvangelist]

Yes, but that's the app host side of this. Ideally, we'd define our own resource type (I believe that would help us long-term), as we have a different set of needs and extended configurations. For example, I'd imagine something like this:

public class AzureCosmosDBRespositoryResource(string name, string? connectionString)
    : AzureCosmosDBResource(name, connectionString)
{
    // TODO: determine what else we might need...
    //       but since `AzureCosmosDBResource` isn't sealed we can extend it.
}

Then we'd have to define extensions on the IDistributedApplicationBuilder, consider pseudo code:

public static class Extensions
{
    public static IResourceBuilder<AzureCosmosDBRespositoryResource> AddAzureCosmosDBRespository(
        this IDistributedApplicationBuilder builder,
        string name,
        string? connectionString = null)
    {
        // ... consider delegating to AddAzureCosmosDB
    }
}

For the .NET Aspire component side of things, we need to control the narrative for the CosmosClient creation. I'm not so sure that I agree with @mumby0168 on exposing the CosmosClient to the user. We've been trying to abstract that away, as it's API has a steep learning curve. I'd much rather just expose the IRepository.

I'd imagine the component side of things would register the library for DI, exposing something like:

var builder = WebApplication.CreateBuilder(args);

builder.AddAzureCosmosDBRepository("cdbr");

[peteraritchie]

+1 on not exposing the CosmosClient, unless it is only through DI.

At the apphost layer, you're only declaring abstract resources. I'm thinking (I don't see it explicitly described anywhere) that AzureCosmosDBCloudApplicationBuilderExtensions.AddAzureCosmosDB is effectively declaring a CosmosDB Account to the distributed App model. The AddDatabase would be adding a either a container or a database (It's not clear which). That would give everything something like AspireCosmosRepositoryExtensions.AddAzureCosmosRepository to control the narrative in creating a CosmosClient, Database or Container.

i.e., even if I had a repository-specific IResource at the app hosting side, I'd still need to describe a Cosmos account and database/container in a way that is agnostic from any resource's framework. I could have one Cosmos account and two databases/containers, one database used by a .NET app, another used by a Node app. I need to be able to describe those relationships in AppHost--which I wouldn't be able to do if there is not an azure-cosmos-dotnet-repository component for Node.

Caveat: Aspire is new and I might have made an incorrect assumption somewhere. And I can't seem to get an Aspire app working with Cosmos :/

[peteraritchie]

...think of the AppHost describing infrastructure that is used by a resource to instantiate usages of that infrastructure with specific clients/gateways/adapters.

[peteraritchie]

ahh, looks like something's missing docs-/library-wise: dotnet/aspire#1098 (comment)

[boylec]

One thing that would be amazing is more obvious support for abstract types - including as aggregate roots for the repositories - (with discriminator based polymorphic deserialization and the like).

Assume that people are going to want to do this and support it out of the box with very low (or no) additional effort beyond adding System.Text.Json polymorphic serialization attributes or contracts. Offer easy to use extensibility points for taking control of the serialization.

Disable strict type checking by default and cover it all in depth in the docs.