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
* > "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
* Buf (https://buf.build/) - a useful tool for static protobuf linting, backwards compatiblity checks and introspection
marked this post as