Remove the requirement that messages conform to GRPCPayload on the server #886
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
…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.
Lukasa
reviewed
Jul 10, 2020
Lukasa
approved these changes
Jul 13, 2020
| ) | ||
| } | ||
| public class _BaseCallHandler<Request, Response>: GRPCCallHandler { | ||
| public let codec: ChannelHandler |
There was a problem hiding this comment.
Should this also be underscored, for consistency? We don't actually want users touching it.
Lukasa
approved these changes
Jul 13, 2020
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
Closed
Closed
glbrntt
added a commit
to glbrntt/grpc-swift
that referenced
this pull request
Jul 15, 2020
Motivation: Recent work in grpc#886 and grpc#889 made `GRPCProtobufPayload` redundant. Since we broke this work into multiple PRs we temporarily dropped support for custom `GRPCPayload`s on the server. This PR adds that back. Modifications: - Add `GRPCPayload` support back to the server by adding the relevant call handler factory functions - Re-enable the custom payload tests - Add a few more custom payload tests (since they were limited to just bidirectional streaming) Result: - Clients and servers support `SwiftProtobuf.Message` and `GRPCPayload` separately without using `GRPCProtobufPayload` to bridge between them.
glbrntt
added a commit
that referenced
this pull request
Jul 15, 2020
Motivation: Recent work in #886 and #889 made `GRPCProtobufPayload` redundant. Since we broke this work into multiple PRs we temporarily dropped support for custom `GRPCPayload`s on the server. This PR adds that back. Modifications: - Add `GRPCPayload` support back to the server by adding the relevant call handler factory functions - Re-enable the custom payload tests - Add a few more custom payload tests (since they were limited to just bidirectional streaming) Result: - Clients and servers support `SwiftProtobuf.Message` and `GRPCPayload` separately without using `GRPCProtobufPayload` to bridge between them.
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:
To support payloads other than
SwiftProtobuf.Messagewe required thatall messages conform to
GRPCPayload. For protobuf messages we addedGRPCProtobufPayloadwhich provides a default implemenation ofGRPCPayloadfor protobuf messages. We generated this conformance forall 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
GRPCPayloadin addition toprotobuf, however, support for protobuf will not be via the
GRPCProtobufPayloadprotocol.This PR adjusts server components such that they are not constrained to
GRPCPayload. At the moment onlySwiftProtobuf.Messageis supported.Once the client side has had the same treatment and
GRPCProtobufPayloadno longer inherits fromSwiftProtobuf.Message,support for
GRPCPayloadwill be added back.Modifications:
HTTP1ToGRPCServerCodechas had the message encoding and decodingremoved. It now deals in
ByteBuffers rather than request/responsemessages.
GRPCServerCodecHandlerwhich sits between theHTTP1ToGRPCServerCodecand_BaseCallHandlerhas been added whichserializes/deserializes messages.
the transition has completed.
Result:
are place on the
initof public handlers instead.GRPCProtobufPayloadis no longer required on the server.