Review the UX experience in dashboard for cases where having a launchUrl different to the app/endpoint url is required.

[maryamariyan]

Existing use case:

For example, check out this echo-bot sample on microsoft/teams-ai

• In launchSettings.json, the launchUrl and applicationUrl are not related.
• In this example, launchUrl is teams.microsoft.com.

Consideration:

• If it isn't possible to show launchUrl in the dashboard, is there already a good way to dynamically pick up (get) the launchUrl value and use it in (for example) in the webfrontend project?

For more details, refer back to https://github.com/dotnet/aspire/issues/812#issuecomment-1815753065

[smitpatel]

@maryamariyan - If I understand correctly, in the sample here echobot is a bot which is installed in teams already so you want to start serving the bot on specified URL but want to launch teams.microsoft.com to test out the bot. Is that correct?

[maryamariyan]

Chatted offline with @smitpatel.

Using the solution in Azure-Samples/openai, tried placing two replicas for the teams app:

 builder.AddProject<Projects.TeamsApp>("teamsapp")
    .WithReference(apiservice)
+    .WithReplicas(2);

and we investigated how load balancing is done and confirmed both replicas may end up getting used:

[smitpatel]

Here is the summary of discussion I had with @maryamariyan In a scenario when developing a teams app, you would create an teams app which is like web API but serving traffic to be consumed by a teams client. So there is an endpoint where API calls are made but way to talk to the endpoint is through teams client so launch URL is set to teams. Such scenario could happen in different app also when user have to use another website/app to make calls to endpoint to test it out. We tested out with and without replicas, with replicas there is no way for teams to connect to particular replica so it will just try to connect to applicationUrl (exposed endpoint from ExecutableReplicaSet) which will load balance out to either replica. So showing launchUrl may be not right thing always.

We have few options to show for endpoint when applicationUrl and launchUrl are diverging

• We should launchUrl as-is. Hitting the URL may not necessarily connect to that replica. (This can create confusing state that for a project which is failed still has endpoint which can be accessed - which doesn't work in non-divergent case)
• We should show endpoint URL which may not be browsable but that case exist already for some project right now.

If we add a summary row for replica set (to group replicas of same project together), we can show launchUrl for replica set and individual replicas will still follow above set.

We need to decide what we want to show in UI. Tagging folks for thoughts - @leslierichardson95 @tlmii @davidfowl @DamianEdwards

[davidfowl]

Related to https://github.com/dotnet/aspire/issues/567

[DamianEdwards]

If we add a summary row for replica set (to group replicas of same project together), we can show launchUrl for replica set and individual replicas will still follow above set.

This is what I'd expect I think.

[leslierichardson95]

@smitpatel I also like the idea of adding a summary row for the replica set too since that seems like the clearest, most transparent option.

[leslierichardson95]

@DamianEdwards, @tlmii, and @smitpatel, as a possible idea for addressing the replica grouping situation overall, can we maybe adopt a tree view experience in the different tables, where the user can expand a row to view all the replicas and their respective information (see attached, sketchy image)?

[tlmii]

I think that's a fairly ideal display but our current DataGrid component does not support it directly. So we'd need to evaluate our options (add support to the underlying grid? Roll our own grid? Hack it together on top of the existing grid?) to see how it could be accomplished.

[smitpatel]

Grid nesting for the win.

[davidfowl]

cc @mitchdenny

[mitchdenny]

@davidfowl did you tag me because adding replicas results in the data not showing up on the dashboard correctly?

[davidfowl]

I wanted to re-test this scenario with the preview3 logic.

[davidfowl]

@maryamariyan where is the app you were testing?

[maryamariyan]

@maryamariyan where is the app you were testing?

Here is the app: https://github.com/Azure-Samples/openai/tree/main/End_to_end_Solutions/GithubRepoAssistant

I'll take a look and let you know how it reproduces

[maryamariyan]

Testing again today. Given launchSettings.json below for the teams app:

{
    "profiles": {
        "Microsoft Teams (browser)": {
            "commandName": "Project",
            "dotnetRunMessages": true,
            "launchBrowser": true,
            "launchUrl": "https://teams.microsoft.com/",
            "applicationUrl": "http://localhost:5130",
            "environmentVariables": {
                "ASPNETCORE_ENVIRONMENT": "Development"
            },
            "hotReloadProfile": "aspnetcore"
        }
    }
}

I see dashboard:

It is not what I expected because in the teams app case, http://localhost:5130 doesn't navigate to anywhere, but the launchUrl will navigate to teams.

[davidfowl]

@drewnoakes and @mitchdenny This is a dashboard/api problem. We need to split the endpoint from the display URL in the API (if that doesn't already exist).

[mitchdenny]

Maybe we can kill two birds with one stone here. I've been wanting to be able to annotate resources with a URI/callback mechanism that could be invoked from the dashboard. We could start with a URI. Then, for resources where we detect a launchUrl in the launch profile we can append that annotation.

This same bit of UX would be used for commanding such as restarting services etc when we get there.

[davidfowl]

This doesn't feel like commanding (which has implications on auth). This feels like data.

[davidfowl]

@maryamariyan This will be easier to do after my changes. Would you be interested in sending a PR for this still?