grpc-ecosystem / grpc-ecosystem/grpc-spring
Support *not* autoconfiguring client and server when address starts with "none"
- 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
Assessment
This issue has not been assessed yet.