Use gRPC to communicate data from app host to dashboard #1476
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The UI will have a single object type for all resources, treating the uniformly. That object has both a fixed set of fields, and now its own extensible metadata. In the protocol between ResourceService and Dashboard, we'll need an extensible way to model these resource data. This allows the UI to work with resource types it hasn't seen before.
We are moving towards removing `Aspire.Hosting`'s reference to `Aspire.Dashboard`. In this new model we will have different types on the back end and front end. - DCP has its own types (e.g. `CustomResource`), which remain untouched, and exist only on the back end. - `ResourceSnapshot` is a new abstract base class for `ContainerSnapshot`, `ExecutableSnapshot` and `ProjectSnapshot`. These are immutable, have no view-specific data, and will only be used on the back end. In the near future, these objects will be used to populate gRPC messages. - `ResourceViewModel` remains, though only on the front end. It no longer has subclasses. We are designing the dashboard to support arbitrary resource types. In the near future, these objects will be constructed and updated in response to gRPC messages. As the front end no longer has subclasses of `ResourceViewModel`, some of the hard-coded resource-specific logic has been changed to work on the additional data within a resource. We also introduce a `KnownResourceTypes` static class with consts for known resource type names (e.g. "Container").
Uses the gRPC `.proto` file added in a previous commit (with some small changes) to model data sent between the back end (app host) and front end (dashboard). Currently this occurs within the same process, but future work will split the dashboard out of the app host. - Object flow is now "DCP -> snapshots -> gRPC messages -> view models". - Move `DashboardWebApplication` initialization out of `DcpHostService` and into the new `DashboardWebApplicationHost` in preparation for future split. - Split `ResourceSubscription`/`ResourceChange`/`ResourceChangeType` into both snapshot and view model versions, for use on back/front ends respectively.
This was missed in a previous commit where we renamed ResourceDataKeys to KnownProperties.
We don't use this consistently throughout. Plenty of places still require a unique resource name as a key. If we want to change this later, we should do it wholesale across the system in future work.
JamesNK
reviewed
Jan 4, 2024
|
@JamesNK PTAL |
|
I got your branch and ran the app. Projects aren't displaying a PID or project file on resources page:
|
JamesNK
reviewed
Jan 4, 2024
JamesNK
reviewed
Jan 4, 2024
JamesNK
reviewed
Jan 4, 2024
JamesNK
reviewed
Jan 4, 2024
JamesNK
reviewed
Jan 4, 2024
JamesNK
reviewed
Jan 4, 2024
This prevents corruption from concurrent updates of a non-concurrent dictionary.
karolz-ms
approved these changes
Jan 4, 2024
Fixed:
|
JamesNK
approved these changes
Jan 5, 2024
|
Excellent work everyone! |
drewnoakes
added a commit
to drewnoakes/aspire
that referenced
this pull request
Jan 5, 2024
Follows comments on dotnet#1476. Uses a component for the application name, which might not be available during the first render, and may require an additional render once the client has connected to the server and retrieved the name.
drewnoakes
added a commit
that referenced
this pull request
Jan 8, 2024
* Use component for application name Follows comments on #1476. Uses a component for the application name, which might not be available during the first render, and may require an additional render once the client has connected to the server and retrieved the name. * Use OnInitializedAsync * Prefix field name with underscore * Cancel wait on connection if component disposed
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Includes PR #1415, with feedback from that PR addressed here.
This is another step towards #1003. Ultimately the dashboard will run in a separate process to the app host. That will require a network connection between the processes for data.
This PR splits the front and back end to use separate types, with a gRPC channel between them.
The
.protodefined in #1274 is used here, with some modifications following the integration.Contributes to #436.
Microsoft Reviewers: Open in CodeFlow