Grouping Related Apps In UI

[josephaw1022]

So I was working with on a project of mine and looking at the aspire dashboard and wish that I could have a way to my logically group my apps.

What I am thinking is something that is grouped into something like this

Obviously it wouldn't exactly look exactly like this but I do think having a way to write something like this (whether or not it's called namespace or not) would make it easier to see what's related in the dashboard.

And with that done in the app host we would then see the apps grouped together in the dashboard.

[DamianEdwards]

The current thinking is #521 would cover this. This work isn't currently scheduled for our initial release though but pls do add your support for it there.

[josephaw1022]

The current thinking is #521 would cover this. This work isn't currently scheduled for our initial release though but pls do add your support for it there.

This seems related in the sense that you're "grouping" resources. But #521 seems to specifically be about injecting environment variables in multiple resources at once.

This issue is specifically about grouping a set of resources in the ui. And making it easier to associate specific resources are associated together. Whether or not a "grouping of resources " share any env variables is not a concern for what this proposal aims to accomplish.

[davidfowl]

Are you thinking about this solely as a UI operation?

[josephaw1022]

@davidfowl Yes, exactly!

What I'm envisioning is a way to programmatically organize resources into specific "groups" or "namespaces" within the dashboard. This concept would work as follows:

Default Behavior: If no namespace is specified in the app host program.cs file, then the dashboard retains its current appearance, showing all resources without any namespace categorization.

Partial Namespace Specification: If a subset of resources is assigned to a namespace, the dashboard should display these resources under the specified namespace. Resources without a specific namespace assignment would be grouped into a 'default' namespace. This approach ensures clarity and distinction between categorized and uncategorized resources.

Full Namespace Utilization: In scenarios where all resources are associated with a namespace, the dashboard would operate similarly to the second point, but without the need for a default namespace. Each resource would be displayed under its respective namespace, providing a clear and organized view of the system's structure.

In the Kubernetes context, I understand that different namespaces imply certain nuances in communication strategies, particularly concerning Network Policies. However, in the context of Aspire Orchestration, I'm proposing the use of namespaces as a logical grouping mechanism. For instance, resources A, B, and C could be grouped under an 'auth' namespace, indicating their related functionalities, while resources X, Y, and Z could be grouped under the 'monitoring' namespace, reflecting their logical association. Auth and monitoring are just examples to illustrate the point. So, to be clear, this doesn't aim to affect any functionality besides dashboard visualization as that is the only thing that I am concerned about currently.

What I have in mind is something grouping the aspire resources akin to how Rancher groups namespaces.

Just something similar to this 👆 in Aspire would make it easier to identify what is logically related to what in an "app host program.cs file" that is potentially orchestrating 6+ resources.

[lukedukeus]

I've run into this a few times for different projects using aspire. Right now I am working on a distributed system that has many nodes. Each node has its own database and C# project, and docker contaners. Rather than seeing a list of 30+ services, it would be nice if I could group them by node.

I have found that the .WithParentRelationship() method works for visually grouping resources, as long as the parent resource is a docker container or project. I'm not sure why it doesnt work for other types of resources, but I'm guessing GroupResource should hook into the resources lifetimes to accuratly update the state, and have the start / stop action work for the entire group.

GroupResource:

    public class GroupResource(string name) : Resource(name), IResourceWithWaitSupport
    {
    }

GroupResourceBuilderExtensions:

    public static class GroupResourceBuilderExtensions
    {
        public static IResourceBuilder<GroupResource> AddGroup(this IDistributedApplicationBuilder builder, [ResourceName] string name)
        {
            ArgumentNullException.ThrowIfNull(name);

            var groupResource = builder.AddResource(new GroupResource(name))
                .WithAnnotation(new ContainerImageAnnotation() { Image = "scratch" });

            return groupResource;
        }
    }

Driver code:

    private static IResourceBuilder<GroupResource> AddServer(this IDistributedApplicationBuilder builder, string name, IResourceBuilder<PostgresServerResource> databaseServer)
    {
        var server = builder.AddGroup(name);

        var serverDatabase = databaseServer.AddDatabase("Main-Database").WithParentRelationship(server.Resource);
        var eventsDatabase = databaseServer.AddDatabase("Events-Database").WithParentRelationship(server.Resource);

        builder.AddProject<Projects.Sentry_Controller_API>("Server-API")
            .WithReference(serverDatabase)
            .WaitFor(serverDatabase)
            .WithReference(eventsDatabase)
            .WaitFor(eventsDatabase)
            .WithParentRelationship(server.Resource);

        return server;
    }

Output:

@davidfowl Is there anything like this already in the works / a better way to do this, or should I open a new issue for this?

[davidfowl]

Not actively being worked on no.