feat: Decouple NamedService from the transport feature
#969
Conversation
The `tonic::transport::NamedService` trait is gated by the `transport` feature. This means that generated server implementations can only include this implementation when the `transport` feature is enabled on `tonic-build`; and if the `transport` feature is not used at generation-time, then a server cannot be used with `tonic::transport::Server` at runtime. We would like to publish a crate including generated protobuf/gRPC bindings that does not _require_ a dependency on the `transport` feature (and its fairly heavyweight dependency tree). But it would be nice if its servers could still be used by applications that want to use `tonic::transport::Server`. By decoupling the `NamedService` trait from the `transport` feature, `tonic-build` can be changed to always provide an implementation for this trait without requiring all of the `transport` dependencies. This enables generated servers to be used with `tonic::transport::Server`.
|
I wonder if this counts as a breaking change? I don't think so...so maybe we can get this in a patch release for yall. What do you think? |
|
@LucioFranco I don't think this is a breaking change, as it's purely additive. We retain the That said, I worked around this by avoiding the It still seems worth pursuing, though, I think. I'll fix up the CI errors... |
|
Yeah, I think its worth it. I suspect this will be a feature that will live beyond the removal of the |
|
@olix0r do you still want this feature? |
|
We could probably get this into the next release |
|
I think I'd still like this... I'm juggling a few things at the moment but I'll try to get back to this; or, if someone else has a chance to take it over that would be great, too. Cc @hawkw |
|
Happy to help get this ready to merge, thanks for the ping! |
|
@hawkw 👍 I wanna try and get some sort of tonic release this week and we could get this merged. |
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
fix & update hyperium/tonic/hyperium#969
| fn generate_transport( | ||
| fn generate_named( | ||
| server_service: &syn::Ident, | ||
| server_trait: &syn::Ident, | ||
| service_name: &str, | ||
| ) -> TokenStream { | ||
| let service_name = syn::LitStr::new(service_name, proc_macro2::Span::call_site()); | ||
|
|
||
| quote! { | ||
| impl<T: #server_trait> tonic::transport::NamedService for #server_service<T> { | ||
| impl<T: #server_trait> tonic::server::NamedService for #server_service<T> { | ||
| const NAME: &'static str = #service_name; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
i considered just folding this back into the generate function, because it isn't generating a ton of code, and it no longer needs to be factored out for feature-flagging reasons, but i don't have a strong opinion here...
There was a problem hiding this comment.
Yeah maybe but we can do that in another refactor nbd
|
@LucioFranco i think this is ready for a review unless i've missed anything? i can't mark the branch as "ready for review" because i didn't open it... |
| fn generate_transport( | ||
| fn generate_named( | ||
| server_service: &syn::Ident, | ||
| server_trait: &syn::Ident, | ||
| service_name: &str, | ||
| ) -> TokenStream { | ||
| let service_name = syn::LitStr::new(service_name, proc_macro2::Span::call_site()); | ||
|
|
||
| quote! { | ||
| impl<T: #server_trait> tonic::transport::NamedService for #server_service<T> { | ||
| impl<T: #server_trait> tonic::server::NamedService for #server_service<T> { | ||
| const NAME: &'static str = #service_name; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Yeah maybe but we can do that in another refactor nbd
LucioFranco
changed the title
NamedService from the transport featureNamedService from the transport feature
|
Thanks! |
Motivation
The
tonic::transport::NamedServicetrait is gated by thetransportfeature. This means that generated server implementations can only
include this implementation when the
transportfeature is enabled ontonic-build; and if thetransportfeature is not used atgeneration-time, then a server cannot be used with
tonic::transport::Serverat runtime.We would like to publish a crate including generated protobuf/gRPC
bindings that does not require a dependency on the
transportfeature(and its fairly heavyweight dependency tree). But it would be nice if
its servers could still be used by applications that want to use
tonic::transport::Server.Solution
By decoupling the
NamedServicetrait from thetransportfeature,tonic-buildcan be changed to always provide an implementation forthis trait without requiring all of the
transportdependencies. Thisenables generated servers to be used with
tonic::transport::Server.