Add gRPC server and client samples with Spring Integration by cppwfs · Pull Request #377 · spring-projects/spring-integration-samples

cppwfs · 2026-02-12T16:05:23Z

Implement gRPC examples demonstrating Spring Integration's gRPC support for both server and client scenarios.

Server implementation:

Add GrpcInboundGateway with service routing for multiple RPC patterns
Implement unary RPC and server streaming streaming methods
Configure HelloWorldService with message routing based on service method headers

Client implementation:

Add GrpcOutboundGateway for unary and streaming response handling
Implement ApplicationRunner beans to demonstrate both communication patterns

Implement gRPC examples demonstrating Spring Integration's gRPC support for both server and client scenarios. Server implementation: - Add `GrpcInboundGateway` with service routing for multiple RPC patterns - Implement unary RPC and server streaming streaming methods - Configure HelloWorldService with message routing based on service method headers Client implementation: - Add `GrpcOutboundGateway` for unary and streaming response handling - Implement ApplicationRunner beans to demonstrate both communication patterns

rishiraj88 · 2026-02-12T22:42:49Z

Looks promising. Thanks.

artembilan

It also would be great to have tests for these new examples.
This way the samples project would serve a role of smoke tests for core project.
Thanks

artembilan · 2026-02-12T23:14:55Z

gradle.properties

 springBootVersion=4.1.0-SNAPSHOT
+protobufVersion=4.29.4
+protobufPluginVersion=0.9.4
+grpcVersion=1.78.0


That's not where we keep versions.
See ext block in the build.gradle.
And I guess we don't need protobufPluginVersion variable since it can simply go to the plugin definition itself.

artembilan · 2026-02-12T23:16:26Z

build.gradle

+
+	dependencies {
+		implementation 'org.springframework.boot:spring-boot-starter-integration'
+		implementation "org.springframework.integration:spring-integration-grpc:7.1.0-SNAPSHOT"


Why do we need explicit SI version here?
More over there is a dedicated variable in the ext block.

build.gradle

artembilan · 2026-02-12T23:17:45Z

build.gradle

+		//Test
+		testImplementation 'org.springframework.boot:spring-boot-starter-test'
+		testImplementation 'org.springframework.integration:spring-integration-test'
+		testRuntimeOnly 'org.junit.platform:junit-platform-launcher'


If we need this, then it probably should go to the common deps section for all the projects.

artembilan · 2026-02-12T23:18:22Z

build.gradle

+
+		//Test
+		testImplementation 'org.springframework.boot:spring-boot-starter-test'
+		testImplementation 'org.springframework.integration:spring-integration-test'


I think this one has to be in the common deps section.
If that is not the case, we should consider to improve the project.

artembilan · 2026-02-12T23:19:20Z

build.gradle

+
+	dependencies {
+		implementation 'org.springframework.boot:spring-boot-starter-integration'
+		implementation "org.springframework.integration:spring-integration-grpc:7.1.0-SNAPSHOT"


If you fix the server sample, I guess same has to be done for the client one, too.

artembilan · 2026-02-12T23:20:01Z

basic/grpc-server/src/main/resources/application.properties

@@ -0,0 +1 @@
+spring.grpc.server.port=9090


New line in the end of each file.
I believe there supposed to be an option in IntelliJ IDEA.

artembilan · 2026-02-12T23:24:45Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+			MessageChannel grpcInputChannelStreamResponse,
+			FluxMessageChannel grpcStreamOutputChannel) {
+		//TODO: Need advice, there has to be a better way than what I have below (or is this a bug in the
+		// GrpcOutboundGateway?


OK. Let's debug it together to see what is going on!

Looks like we don't need this anymore.
Plus, the gateway could be created from the Grpc DSL factory.

artembilan · 2026-02-17T17:37:17Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+			MessageChannel grpcInputChannelStreamResponse,
+			FluxMessageChannel grpcStreamOutputChannel) {
+		//TODO: Need advice, there has to be a better way than what I have below (or is this a bug in the
+		// GrpcOutboundGateway?


Looks like we don't need this anymore.
Plus, the gateway could be created from the Grpc DSL factory.

artembilan · 2026-02-17T17:38:34Z

.../grpc-client/src/test/java/org/springframework/integration/samples/grpc/GrpcClientTests.java

+ * @author Glenn Renfro
+ */
+@SpringBootTest(properties = {
+		"spring.main.web-application-type=none",


If we don't use web, then this looks suspicious.
As well as the next line.
Why do we need to override some bean?

artembilan · 2026-02-17T17:41:52Z

.../grpc-client/src/test/java/org/springframework/integration/samples/grpc/GrpcClientTests.java

+
+		@Bean
+		@Primary
+		public ApplicationRunner grpcClientStreamResponse() {


Are you sure we need to override these beans for test?
Feels like the sample is very complex, not something what users would expect coming here for beginner's knowledge

Please, elaborate why these bean overrides were not removed.

artembilan · 2026-02-17T17:43:01Z

.../grpc-server/src/test/java/org/springframework/integration/samples/grpc/GrpcServerTests.java

+/**
+ * @author Glenn Renfro
+ */
+@SpringBootTest(webEnvironment = WebEnvironment.NONE)


I'm still not sure what web is doing in these samples...

artembilan · 2026-02-17T17:46:00Z

gradle.properties

@@ -1,5 +1,6 @@
 version=7.1.0
 springBootVersion=4.1.0-SNAPSHOT
+protobufVersion=4.29.4


How that happened that grpcVersion has gone to ext, but not this?

artembilan · 2026-02-17T17:46:58Z

.../grpc-server/src/test/java/org/springframework/integration/samples/grpc/GrpcServerTests.java

+	@BeforeEach
+	void setUp() {
+		Object server = ReflectionTestUtils.getField(this.grpcServerLifecycle, "server");
+		this.grpcServerPort = ReflectionTestUtils.invokeMethod(server, "getPort");


I think something more convenient has to be Spring gRPC, rather than such a hack with reflection.

- Removed POC experimental code

artembilan · 2026-02-18T14:19:51Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+	private static final Log LOG = LogFactory.getLog(ClientHelloWorldConfiguration.class);
+
+	/**
+	 * Creates a managed gRPC channel for communication with the server.


Why not imperative?
This is a method and this is a sample.
Why give readers of these samples a wrong impression about Spring code style and consistency?
Everything what we do here is for community and Spring newcomers.
Would be great to teach them a right lesson and don't overcomplicate the sample code scary impression reasons.

So, see also about those blank lines in method Javadocs.

artembilan · 2026-02-18T14:21:27Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+	 */
+	@Bean(destroyMethod = "shutdownNow")
+	ManagedChannel managedChannel(@Value("${grpc.server.host:localhost}") String host,
+			@Value("${grpc.server.port:9090}") int port) {


As we talked not one time: if method declaration is multi-line, a blank line before before method body.

I also wonder if there are some Spring gRPC auto-configuration for clients.
If there is really a reason to have our own ManagedChannel and those props with hard-coded defaults in the bean definition.

artembilan · 2026-02-18T14:22:50Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+	 *
+	 * @param grpcInputChannelStreamResponse the message channel for streaming response requests
+	 * @param grpcStreamOutputChannel channel that contains the responses
+	 * @param replyTimeout the time in seconds to await for the response.  Defaults to 1 second.


Why no consistency?
The previous example talks about milliseconds instead.

artembilan · 2026-02-18T14:27:59Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+	 */
+	@Bean
+	ApplicationRunner grpcClientStreamResponse(MessageChannel grpcInputChannelStreamResponse,
+			FluxMessageChannel grpcStreamOutputChannel,


Let's see if this channel could be used as a setReplyChannel for consistency with other request in this sample!

artembilan · 2026-02-18T14:29:42Z

...rg/springframework/integration/samples/grpc/configuration/ClientHelloWorldConfiguration.java

+					.doOnSubscribe(subscription -> {
+						HelloRequest request = HelloRequest.newBuilder().setName("Jack").build();
+						Message<?> requestMessage = MessageBuilder.withPayload(request).build();
+						grpcInputChannelStreamResponse.send(requestMessage);


When we do setReplyChannel(replyChannel), this should go outside of the Flux handling.
We can subscribe() and then send: exactly the way how it is recommended by Project Reactor.

artembilan · 2026-02-18T15:23:45Z

basic/grpc-client/src/main/proto/hello.proto

+
+package integration.grpc.hello;
+
+option java_package = "org.springframework.integration.grpc.proto";


We need to double check if these packages have a proper name.
Not sure if without a sample sub-package it is OK to deliver.

artembilan · 2026-02-18T15:25:04Z

.../grpc-client/src/test/java/org/springframework/integration/samples/grpc/GrpcClientTests.java

+
+		@Bean
+		@Primary
+		public ApplicationRunner grpcClientStreamResponse() {


Please, elaborate why these bean overrides were not removed.

artembilan · 2026-02-18T15:28:04Z

.../grpc-client/src/test/java/org/springframework/integration/samples/grpc/GrpcClientTests.java

+
+	@DynamicPropertySource
+	static void grpcServerProperties(DynamicPropertyRegistry registry) throws IOException {
+		mockGrpcServer = ServerBuilder.forPort(0)


That's not correct place to declare server instance.
Plus I wonder if it really should be a socket-based, but not InProcessServerBuilder, like we do in Spring Integration tests.
And another thought: I wonder if there is some Spring gRPC auto-configuration for testing to avoid a lot of boilerplate code like this to confuse end-users.

artembilan · 2026-02-18T15:31:05Z

basic/grpc-server/src/main/resources/application.properties

@@ -0,0 +1 @@
+spring.grpc.server.port=9090


Isn't that a default value?
Why do we need to declare this property here at all?
Probably mention Spring gRPC docs in the README to this sample should be enough.

artembilan · 2026-02-18T15:38:05Z

.../grpc-server/src/test/java/org/springframework/integration/samples/grpc/GrpcServerTests.java

+
+	@BeforeEach
+	void setUp() {
+		this.grpcServerPort = this.grpcServerLifecycle.getPort();


Doesn't look like we need the port as a property.
More over, I believe there should be some channel auto-configuration in Spring gRPC to avoid duplication.
Plus stubbing also can be done by Spring gRPC.
See their docs for more info.

artembilan requested changes Feb 12, 2026

View reviewed changes

Resolve Code Review issues

318138b

artembilan requested changes Feb 17, 2026

View reviewed changes

Resole code review comments

23bf2f3

- Removed POC experimental code

artembilan requested changes Feb 18, 2026

View reviewed changes

		@@ -0,0 +1 @@
		spring.grpc.server.port=9090 No newline at end of file


		package integration.grpc.hello;

		option java_package = "org.springframework.integration.grpc.proto";

Comments

Conversation

cppwfs commented Feb 12, 2026

Uh oh!

rishiraj88 commented Feb 12, 2026

Uh oh!

artembilan left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants