tac demo
tac demo

Reputation: 71

How to use grpc with spring boot

I am new in grpc i don't know how to use it with spring boot but using the below link

  1. https://github.com/saturnism/grpc-java-by-example/tree/master/simple-grpc-server

  2. https://github.com/saturnism/grpc-java-by-example/tree/master/simple-grpc-client

note* : - first is for server project and second is for client project.

i have created a project on grpc with spring boot but i can'nt getting understand one thing in this that in grpc client project how can i use classes which are generated by protobuf in the project of grpc server. because it is not creating any proto file in grpc client project then how can i use the classes of grpc server project in grpc client project or can we create one project for grpc server and client instead of creating a diffrent project for both.

I have two queries to ask related to this question one:- 1. How to use classes of grpc generated by protobuf compiler in another project like if client and server are two different project and only server have proto generated files and client wants to use same classes.

  1. How can i create all these thing in a single project means client and server in one project and then how can i run this project with step by step demo.

Upvotes: 2

Views: 6769

Answers (4)

Nick Dong
Nick Dong

Reputation: 3736

There is yidongnan/grpc-spring-boot-starter (DOC) which implement springboot autoconfiguration starter for both client and server.

It implements @GrpcServer and @GrpcClient.

@GrpcService, which will add service to grpc server and start server automatically.

Annotation that marks gRPC services that should be registered with a gRPC server. If spring-boot's auto configuration is used, then the server will be created automatically. This annotation should only be added to implementations of BindableService (GrpcService-ImplBase).

@GrpcClient, which will create channel and stub for client automatically

Example: @GrpcClient("myClient") <-> grpc.client.myClient.address=static://localhost:9090

nils server sample

nils client sample

Based on these samples, I also implement my simple server and client sample:

ppdouble/springboot-grpc-server-sample

ppdouble/springboot-grpc-client-sample

You can based on those samples implement your project or implement a new springboot autoconfiguration starter.

Upvotes: 0

Vikrant Chaudhary
Vikrant Chaudhary

Reputation: 709

I have used https://github.com/yidongnan/grpc-spring-boot-starter recently. You will get most of the spring features along with grpc using this library.

Upvotes: 0

Konzern
Konzern

Reputation: 128

I have created a sample spring boot grpc application and posted in here https://javabelazy.blogspot.com/

  1. use the dependency net.devh.grpc-server-spring-boot-starter in your pom

  2. create a protofile (sample service code)

service PingPongService { rpc ping(PingRequest) returns (PongResponse) {

option (google.api.http) = { get: "/v1/grpc/{ping}" };
}
  1. generate stubs for proto file using io.grpc:protoc-gen-grpc-java:1.30.0:exe

  2. use nettyserver

  3. set the port to 9090 (default) grpc.server.port=9090 in application properties

Upvotes: 0

Carl Mastrangelo
Carl Mastrangelo

Reputation: 6678

There are two ways you can do this:

  1. Copy the .proto files between the two projects, and have each one generate their own copies of the generated code. This is probably the easiest, and allows you to avoid checking in the generated code into source control. The downside to this approach is that the .proto files can get out of date if you modify one and not the other.

  2. Keep the .proto in the same repository of both the client and server, and make both depend on the generated code. This allows the proto to be modified for the client and server at the same time, but requires the code to live in the same repository (this is sometimes called the "Monorepo" approach). The downside to this is that the client and server repos may get too big, and need to be split up.

Google (the author of Protobuf) typically uses option #2, but many users of Protobuf prefer option 1. I would highly recommend regenerating the classes each time, and not check in the generated code. The ABI of Protobuf classes can change occasionally, and you would lose the backwards compatibility of Protobuf.

Upvotes: 3

Related Questions