Support protobuf separately to GRPCPayload for the client
#889
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: 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
|
The non-generated changes are in: 7a58889 |
Lukasa
reviewed
Jul 14, 2020
Lukasa
approved these changes
Jul 14, 2020
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.
glbrntt
added a commit
that referenced
this pull request
Nov 30, 2020
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 builds on #886 by increasing the surface area of the client APIs
so that they are not constrained to
GRPCPayload. The surface API nowhas variants for
GRPCPayloadandSwiftProtobuf.Message. Internallythe client deals with serializers and deserializers.
Modifications:
GRPCClientChannelHandlerandGRPCClientStateMachineare no longergeneric over a request and response type, rather they deal with the
serialzed version of requests and response (i.e.
ByteBuffers) anddefer the (de/)serialization to a separate handler.
GRCPClientCodecHandlerto handle (de/)serialization ofmessages
payloads conform to
GRPCPayloadGRPCProtobufPayloadis no longer generated and theprotocol is deprecated and has no requirements.
longer required
which contain services, this avoids generating empty files
Result:
GRPCProtobufPayloadis no longer required