subscriber: allow disabling `tonic`'s "transport" feature

[hawkw]

What problem are you trying to solve?

Currently, console-subscriber enables tonic's "transport" feature flag unconditionally. This feature flag pulls in a relatively large set of additional dependencies, including axum (used for routing). This feature is necessary to enable some of the one-stop serve methods on the Server struct.

However, Server also implements the tonic-generated Instrument trait for the gRPC bindings. In some use-cases, users may want to bind the API to an endpoint themselves, rather than using tonic's "transport" feature. It's possible to do this now using the Server type's other trait implementations...but users who do this will still be pulling in a bunch of code they don't actually use.

How should the problem be solved?

We should make it possible to disable tonic/transport. We could feature-flag the APIs that require transport, and make them depend on a "transport" feature flag on console-subscriber.

Any alternatives you've considered?

We may additionally want to look into using tonic's "channel" feature flag, a subset of "transport" that doesn't depend on axum. I think we can probably do this because the serve and serve_with methods don't serve multiple gRPC APIs on the same port, and don't need routing?

How would users interact with this feature?

No response

Would you like to work on this feature?

maybe

[hawkw]

(@LucioFranco might have advice on this?)

[LucioFranco]

I think having a transport feature makes sense. The feature was added for use cases like this. The channel one is just there if you do client only interaction.

[hawkw]

Oh, okay, so it seems like the tokio-console crate (purely a client) should use the channel feature, rather than transport?

[devanbenz]

Is this issue still prevalent? Would love to take it on if so.