grpc-ecosystem / grpc-ecosystem/grpc-spring

Support *not* autoconfiguring client and server when address starts with "none"

Open
#419 10 comments 0 reactions 1 assignee Claimed by @ST-DDT View on GitHub
enhancement
Dominant language
Java
Stars
3.7k
Forks
858
PR merge metrics
No merged PRs in 30d

Description

**The problem**

Currently, annotations `@GrpcService` and `@GrpcClient` autoconfigure the server and the client respectively. For integration testing, we can use in process server and client as explained [here](https://yidongnan.github.io/grpc-spring-boot-starter/en/server/testing.html#integration-tests). In my case, I've a `client-A` that calls `service-A` that calls `client-B` that calls `external-service-B`. Depending on the test scenario, I substitute in process versions for `service-A` and `external-service-B` to test the flow, or use the real ones.

What I'd like to do now is use the same test for calling `service-A` deployed in my integration environment. That means, I only need in process `client-A`, and `service-A` and `client-B` beans shouldn't be created.

**The solution**

Just like in process is given special treatment now, it'd be nice to have the library support this use case by not configuring client/server that begins with `none` in their address. I'd point `client-A` to the remote `service-A` deployed in my integration environment and run the same test I run when I use local `service-A`.

**Alternatives considered**

One way is to use a Spring profile with `@GrpcService` in a `@Configuration` class, such the the beans are created only if Spring profile `integration` isn't active. That's fine, but it makes the Production code coupled with test code.

Another option is to simply let `service-A` and `client-B` beans be created, but not use them. This is very confusing and could lead to bugs since we have no way to tell whether `client-A` is talking to local `service-A`, or remote one.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.