dotnet / aspire

Tools, templates, and packages to accelerate building observable, production-ready apps
https://learn.microsoft.com/dotnet/aspire
MIT License
3.93k stars 480 forks source link

App Model driven "notfiications" and "workflows" #6470

Open mitchdenny opened 1 month ago

mitchdenny commented 1 month ago

With the introduction of ResourceCommandAnnotation we've added the ability for integration developers to offer up actions that users can initiate via the portal. When a command is executed a short lived "toast" notification is displayed to the end user.

I believe that there are further experiences that we may wish to provide via the dashboard to streamline app development which require a more interactive experience. A simple scenario would be prompting for parameter values.

When an application launches that requires parameter values, if they are missing then there will be an exception when they are used and the developer will need to stop debugging and then put the parameters in the config file and then re-launch the app host.

Instead of this we could provide two new APIs in the app model - INotificationService and IDialogService (we can bikeshed the names later). These two interfaces could be used to provide inline experiences in the dashboard.

The notification service could be used to add a persistent notification in a visible location on the dashboard. The notification would have data model that would allow it to be interacted with. Here is just an example:

var notification = _notificationService.AddNotification(new {
  Title = "Missing parameter",
  Description = "Please provide the missing parameter for ...",
  DefaultAction = new NotificationAction("Provide value", async (context, ct) => {
      var dialogResult = await _dialogService.OpenDialogAsync(url);

      if (dialogResult != DialogResult.Cancelled)
      {
        await context.Notification.CloseAsync(ct);
      }
  }
});

A few landmarks to point out. Notifications are persistent until they are cancelled (or an optional timeout is specified). Any code with access to the container in the app host could use this service. The dialog service similarly could be called from anywhere but in this context its called from the default action callback on the notification.

In this case it opens a URL which would become modal on the dashboard and display a webpage which could be offered up either by the app host or a container (allowing for some slick UX scenarios for integrations).