Create a Post
Title
Details
29
Support gRPC
planned
gRPC is a common microservice framework. Commonly used with Protobufs as the encoding, and HTTP/2 as the transport, it is a highly efficient and type safe architecture. It is often said that contract testing is not required, due to forwards/backwards compatibility encoded into the schemas. Arguments for gRPC and Protobuf support in Pact See https://developers.google.com/protocol-buffers/docs/overview * > "You can add new fields to your message formats without breaking backwards-compatibility; old binaries simply ignore the new field when parsing. So if you have a communications protocol that uses protocol buffers as its data format, you can extend your protocol without having to worry about breaking existing code." * Whilst this won’t break the “contract”, it may actually not be a plausible situation. There are no guarantees that the actual RPC service will still work as expected The protocol definition itself doesn’t guarantee it can handle all situations the consumers expect to use: * Proto 3 removes “mandatory fields” - "Making every field optional provides a clearer contract to clients. They are explicitly responsible for checking that every field has been populated with something valid." * This means specification examples (ala Pact) are very important to ensuring the functionally contract behaviour * Similar issues to the challenges of "Optional" or "Any" schemas in SOAP SOA architectures Backwards guarantee doesn’t tell you _forwards_ compatibility i.e. it doesn’t help you coordinate a release OneOf semantics - see https://developers.google.com/protocol-buffers/docs/proto3#backwards-compatibility-issues The protocol buffer is separate to the HTTP endpoint serving it. See value prop from above It is absolutely possible to break a proto file by modifying numbered tags (field identifiers) or removing fields Related Resources * Buf ( https://buf.build/ ) - a useful tool for static protobuf linting, backwards compatiblity checks and introspection
6
Load More