You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
What problem are you trying to solve?
Currently,
console-subscriber
enablestonic
's "transport" feature flag unconditionally. This feature flag pulls in a relatively large set of additional dependencies, includingaxum
(used for routing). This feature is necessary to enable some of the one-stopserve
methods on theServer
struct.However,
Server
also implements the tonic-generatedInstrument
trait for the gRPC bindings. In some use-cases, users may want to bind the API to an endpoint themselves, rather than usingtonic
's "transport" feature. It's possible to do this now using theServer
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 requiretransport
, and make them depend on a "transport" feature flag onconsole-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 onaxum
. I think we can probably do this because theserve
andserve_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
The text was updated successfully, but these errors were encountered: