Resource server protocol changes

[davidfowl]

As part of the work to support custom resources in the dashboard (#2390) there are several improvements that we should consider making to the resource server API:
 

• Allow resource properties to be marked as secret #5065
• Make the list of endpoints/urls more general purpose and support named urls. For e.g. we want to be able to navigate to the portal for azure resources.
• Feedback here about the service and endpoints split (Show all resource endpoints on resource grid #2413 (comment)) cc @JamesNK
• Model replicas explicitly. Today we have a flat list of resources and replicas are found based on naming. We can make this explicit.
• Allow setting both the state and the state icon or icon type (Support custom styles for resource style #3210)
• Bound number of console logs retained in the dashboard process #4849

[kvenkatrajan]

@davidfowl , I am not sure I understand this request :

Make the list of endpoints/urls more general purpose and support named urls. For e.g. we want to be able to navigate to the portal for azure resources.

Can you give example of variations of urls for local/azure resources you would expect?

The other 2 are clear - Thanks!

[JamesNK]

What about adding references to resources? i.e. what resources is a resource referencing. We can show that in the resource detail pane.

builder.AddProject<Projects.MyFrontend>("frontend")
       .WithReference(basketService)
       .WithReference(catalogService.GetEndpoint("http"));

In the example above, the frontend resource would have two references. A reference would have:

• Resource name
• Endpoint name
• Value - URI string?

You could try to reverse engineer this by looking at environment variables, but it would be a pain in the butt. Much easier to model it explicitly.

[drewnoakes]

Another potential addition is window size for logs. The server can limit the amount of history it sends easily enough, and I believe ACA does this today. The dashboard client currently appends logs without rolling old messages out of the window, which will eat memory indefinitely. We should synchronise the window size between client and server, so the server doesn't send data the client won't display, and so the client can roll old messages out. Perhaps the client specified the window size in the request.