Allow separate generation of test clients #881
Merged
Conversation
This file contains 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
Motivation: Users should be able to generate their test clients separately to their real clients so that their real clients can be public and their test clients internal. Modifications: - Allow test clients to be generated separately from real clients - Add an option to control whether conformance is generated; this allows test clients to be generated separately from real clients when the service and messages are defined in a single file without duplicating the conformance. - Expand on the plugin documentation. Result: Resolves grpc#878
glbrntt
added
🔨 semver/patch
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjust the server components such they only support SwiftProtobuf. Once the client side has had the same treatment (and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`), support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 10, 2020
…rver Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
that referenced
this pull request
Jul 13, 2020
…rver (#886) Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: #738, #778, #801, #837, #877, #881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR adjusts server components such that they are not constrained to `GRPCPayload`. At the moment only `SwiftProtobuf.Message` is supported. Once the client side has had the same treatment and `GRPCProtobufPayload` no longer inherits from `SwiftProtobuf.Message`, support for `GRPCPayload` will be added back. Modifications: - The `HTTP1ToGRPCServerCodec` has had the message encoding and decoding removed. It now deals in `ByteBuffer`s rather than request/response messages. - An additional `GRPCServerCodecHandler` which sits between the `HTTP1ToGRPCServerCodec` and `_BaseCallHandler` has been added which serializes/deserializes messages. - Custom payload tests have been commented out. They will return when the transition has completed. Result: - Servers only support SwiftProtobuf - Genertic constraints on the server have been removed; the constraints are place on the `init` of public handlers instead. - `GRPCProtobufPayload` is no longer required on the server.
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: grpc#738, grpc#778, grpc#801, grpc#837, grpc#877, grpc#881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on grpc#886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
glbrntt
added a commit
that referenced
this pull request
Jul 14, 2020
Motivation: To support payloads other than `SwiftProtobuf.Message` we required that all messages conform to `GRPCPayload`. For protobuf messages we added `GRPCProtobufPayload` which provides a default implemenation of `GRPCPayload` for protobuf messages. We generated this conformance for all protobuf messages we saw. This lead to a number issues and workarounds including: #738, #778, #801, #837, #877, #881. The intention is to continue to support `GRPCPayload` in addition to protobuf, however, support for protobuf will not be via the `GRPCProtobufPayload` protocol. This PR builds on #886 by increasing the surface area of the client APIs so that they are not constrained to `GRPCPayload`. The surface API now has variants for `GRPCPayload` and `SwiftProtobuf.Message`. Internally the client deals with serializers and deserializers. Modifications: - `GRPCClientChannelHandler` and `GRPCClientStateMachine` are no longer generic over a request and response type, rather they deal with the serialzed version of requests and response (i.e. `ByteBuffer`s) and defer the (de/)serialization to a separate handler. - Added `GRCPClientCodecHandler` to handle (de/)serialization of messages - Clients are no longer constrained to having their request/response payloads conform to `GRPCPayload` - Conformance to `GRPCProtobufPayload` is no longer generated and the protocol is deprecated and has no requirements. - Drop the 'GenerateConformance' option from the codegen since it is no longer required - Reintroduce a filter to the codegen so that we only consider files which contain services, this avoids generating empty files - Regenerate code where necessary Result: - `GRPCProtobufPayload` is no longer required
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Users should be able to generate their test clients separately to their
real clients so that their real clients can be public and their test
clients internal.
Modifications:
test clients to be generated separately from real clients when the
service and messages are defined in a single file without duplicating
the conformance.
Result:
Resolves #878