[feature request] connect to multiple grpc services

[zhouzhuojie]

This is a really good grpc frontend! I was planning to use it as a debugging/curl style hub for all our grpc backends. The problem I saw is that to support multiple backends, one has to run the command for each grpc service, and then expose it to different ports if the grpcui instances are deployed in one container.

Is it possible to connect to multiple grpc services with single exposed port and united UI? Is it possible for the UI to consolidate and support the selection for which service we want to talk to?

Thanks!

[jhump]

@zhouzhuojie, what you describe is certainly do-able, but seems like it could complicate the command-line interface a bit or require a rather different GUI (which allows the backend to be selected in the UI instead of on the command-line). While this is certainly a useful improvement, I'm not sure how quickly we'll be able to address it.

In the meantime, if you are familiar with Go, you may be better off building your own program, that uses these Go packages as a library. If you look at the grpcui.go source (in cmd/grpcui), you can see how easy it is to create an HTTP handler that provides this UI by importing the github.com/fullstorydev/grpcui/standalone package. From there, you have a couple of options on how this new UI might work:

1. You could have the main package enumerate all backends and generate different URIs for each one. For example, navigating to /foo might show a gRPC UI that issues RPCs to the "foo" service. The root handler (/) could just show a directory listing of all known backends with a hyperlink to go the corresponding gRPC UI page.
2. You could have the various connections be established lazily. You can then provide an HTML form that allows users to enter the desired connection details. Once connected, you could cache them in a map of connection names/addresses -> grpcui stand-alone handlers. From here, it is much like the suggestion above: you could use the URI path to indicate which backend the UI uses. A root handler could still show an index of all established connections. (You could even have code establish the connections automatically, without a web form, by parsing relevant info from the URI and using that to dynamically create gRPC connections.)

Both approaches (statically enumerate backends up-front, or allow them to be established dynamically) require instantiating multiple grpcui stand-alone handlers, one for each backend. When you create the handler, you give it a connection. For the dynamic approach the UI handler would need to inspect the URI path, look up the correct stand-alone handler from the map, and then delegate to that stand-alone handler.

[pradeepmvn]

@jhump Thanks for detailed explanation, it is definitely a nice feature to have..I have made changes to accept different targets and also /list them from a ui endpoint. Instead of localhost:port, grpcui expects 1 or many -t srv=localhost:port https://github.com/pradeepmvn/grpcui/commit/4575d22dbba8b044c0865404aabaae4f8778be00 Would love to submit a PR if this is valuable..

[augi]

@pradeepmvn Did you submit a new PR for this change? I'm asking because this feature would be valuable for me as well. Thanks!

[jhump]

@augi, this feature is still unimplemented.

[jhump]

An interesting idea from another issue (that was a duplicate of this one) that is interesting to consider:

@sheepdreamofandroids said:

The way I see it, there is no need to create any user interface for this. Simply allow a request parameter when opening the page to indicate a host and port. Something like http://grpcui.test.cluster/?server=grpcservice.test.cluster:8980

My usecase would be to deploy one instance of grpcui on our testcluster and have each service link to that ui with the proper parameter set up.

I think supporting a GUI on top of this would actually be simple: a page with a form for collecting the attributes needed to dial the server (in addition to the server address, you'd need other parameters related to connection setup, such as optional TLS settings) that, when done, just navigates to the main UI page with all of the values set as query string params.