Require generated client protocols to accept CallOptions
#865
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
Note: 3c6fe84 contains the actual change and a regenerated Echo client. The other commits are just other clients regenerated. |
Lukasa
requested changes
Jun 30, 2020
Collaborator
Lukasa
left a comment
Lukasa
left a comment
There was a problem hiding this comment.
Great, I generally think this looks good. I've left a few small notes in the diff: nothing major, just some cleanups and thoughts.
glbrntt
force-pushed
the
gb-generated-protocol
branch
from
0fa5d9d to
c310e5c
Compare
Motivation: The generated protocol for clients allows the caller to optionally pass in some `CallOptions`. The generated client conforming to this protocol defaults this argument to `nil` and falls back to default options set on that client in that case. It is therefore possible to call, for example, `theClient.someUnaryRPC(someRequest)` but not `theProtocol.someUnaryRPC(someRequest)`. Without explicitly passing the call options, the protocol offers little value when coding to the protocol rather than to a concrete implementation. Modifications: - Generated client protocols now extend `GRPCClient` (previously the generated client implementations conformed to `GRPCClient` and the protocol) - Generated client protocol requires `CallOptions` - Generated client protocols now have a generated extension for each RPC which does not require call options whose implementation forwards the default call options courtesy of `GRPCClient`. Result: - It is possible to reasonably implement code against the generated protocol rather than a concrete implementation - We lose the ability to call an RPC with `callOptions: nil`
glbrntt
force-pushed
the
gb-generated-protocol
branch
from
c310e5c to
aa11601
Compare
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 1, 2020
Motivation: When consuming gRPC it is often helpful to be able to write tests that ensure the client is integrated correctly. At the moment this is only possible by running a local gRPC server with a custom service handler to return the responses you would like to test. Modifications: This builds on work in grpc#855, grpc#864, and grpc#865. This pull request introduces code generation for the test clients. It provides type-safe wrappers and convenience methods on top of `FakeChannel` and a code-gen option to enable 'TestClient' generation. It also removes an `init` requirement on the `GRPCClient` protocol. Result: Users can generate test clients.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 1, 2020
Motivation: When consuming gRPC it is often helpful to be able to write tests that ensure the client is integrated correctly. At the moment this is only possible by running a local gRPC server with a custom service handler to return the responses you would like to test. Modifications: This builds on work in grpc#855, grpc#864, and grpc#865. This pull request introduces code generation for the test clients. It provides type-safe wrappers and convenience methods on top of `FakeChannel` and a code-gen option to enable 'TestClient' generation. It also removes an `init` requirement on the `GRPCClient` protocol. Result: Users can generate test clients.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 2, 2020
Motivation: When consuming gRPC it is often helpful to be able to write tests that ensure the client is integrated correctly. At the moment this is only possible by running a local gRPC server with a custom service handler to return the responses you would like to test. Modifications: This builds on work in grpc#855, grpc#864, and grpc#865. This pull request introduces code generation for the test clients. It provides type-safe wrappers and convenience methods on top of `FakeChannel` and a code-gen option to enable 'TestClient' generation. It also removes an `init` requirement on the `GRPCClient` protocol. Result: Users can generate test clients.
MrMage
pushed a commit
that referenced
this pull request
Jul 3, 2020
* Provide the codegen with an option to generate test clients Motivation: When consuming gRPC it is often helpful to be able to write tests that ensure the client is integrated correctly. At the moment this is only possible by running a local gRPC server with a custom service handler to return the responses you would like to test. Modifications: This builds on work in #855, #864, and #865. This pull request introduces code generation for the test clients. It provides type-safe wrappers and convenience methods on top of `FakeChannel` and a code-gen option to enable 'TestClient' generation. It also removes an `init` requirement on the `GRPCClient` protocol. Result: Users can generate test clients. * Regenerate * fix type, add assertion * Add "Remaining"
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation:
The generated protocol for clients allows the caller to optionally pass
in some
CallOptions. The generated client conforming to this protocoldefaults this argument to
niland falls back to default options set onthat client in that case.
It is therefore possible to call, for example,
theClient.someUnaryRPC(someRequest)but nottheProtocol.someUnaryRPC(someRequest).Without explicitly passing the call options, the protocol offers little
value when coding to the protocol rather than to a concrete
implementation.
Modifications:
GRPCClient(previously thegenerated client implementations conformed to
GRPCClientand theprotocol)
CallOptionswhich does not require call options whose implementation forwards the
default call options courtesy of
GRPCClient.Result:
protocol rather than a concrete implementation
callOptions: nil