Can I help? :)

[bsideup]

Hey @dsyer! It's been a while :) I am excited to see first-class gRPC support in Spring ecosystem, I remember our conversations back in 2018 about it :)

Let me know if I can help, or if you will prefer to bootstrap things on your own first (I see value in that too!).

I am a long term user of https://github.com/grpc-ecosystem/grpc-spring but would be happy to migrate to the native implementation once it is available for consumption, and, given my advanced usage of it (e.g. through https://github.com/bsideup/grpc-bidi/tree/main/java), I figured it might be helpful to be close and share my use cases.

Thank you, can't wait to see how it will shape up!

[dsyer]

100% you can help. I also used that project the most, so I’m biased, and the issues I opened were slanted to features I found there.

My current conundrum is to figure out if there is any value at all in the autoconfiguration of channels and clients (stubs). The state of the art in the community projects seems to favour that approach (but I prefer the one in https://github.com/DanielLiu1123/grpc-starter). My initial opinion is that it’s better to use the same approach as Spring Boot does with HTTP clients (ie inject a builder/factory where needed). Your opinion, and anyone else if they feel like it, would be valuable.

[bsideup]

@dsyer yay, great! Let me get familiar with the current state (by trying it on some of my pet projects) 👍

BTW I have some ideas of how Spring Boot's Netty server can be reused, allowing for co-existence on the same port.

My current conundrum is to figure out if there is any value at all in the autoconfiguration of channels and clients (stubs)

That's a good question. I do see value in injecting GrpcChannelFactory instead of a custom GrpcClient annotation as it is much less magical. And maybe autowiring channels based on their name, so that one can inject io.grpc.Channel where the bean name would be equal to the channel name, just to avoid channelFactory.createChannel("myChannel") everywhere 👍 A builder would be cool too!

[dsyer]

BTW I have some ideas of how Spring Boot's Netty server can be reused, allowing for co-existence on the same port.

That would be cool. @making also said it could be done with Tomcat in a normal MVC app.

[bsideup]

Correct! There is a Servlet adapter: https://github.com/grpc/grpc-java/tree/master/servlet

[making]

Filed issues #18 and #19 for using the same port

[onobc]

My current conundrum is to figure out if there is any value at all in the autoconfiguration of channels and clients (stubs). The state of the art in the community projects seems to favour that approach (but I prefer the one in https://github.com/DanielLiu1123/grpc-starter).

I too prefer the latter as it uses the registrar/register pattern consistent w/ other Spring projects. It also has a coarse grained annotation that specifies basepackages and/or clients whereas the grpc ecosystem starter has a fine grained annotation model per client.

My initial opinion is that it’s better to use the same approach as Spring Boot does with HTTP clients (ie inject a builder/factory where needed).

I agree w/ first providing the factories as it is simple (and consistent w/ HTTP clients as you pointed out) . We can always add in a richer annotation scanning model later.