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
Pact Consumer Dart
It would be awesome to have a Pact Dart Consumer. My main use case would be to use it on a flutter application that is consumer of multiple pact enabled providers.
Support multiple protocols of Pact for the same application
Currently, you can only have one type of pact for each consumer/provider pair (eg. http or message). This feature would add support for publishing pacts with different protocols, and incorporating them into the can-i-deploy calculations.
Provider driven-contracts with Swagger
(I wanted to get this in as there have been a few conversations - more details to follow) See https://pactflow.io/blog/the-curious-case-for-the-provider-driven-contract/ for more background.
Allow pact-stub-server to respond data that depends on request
Let's make pact-stub-server smarter by allow it to refer request data to be a part of response data like attached picture below. Furthermore, it would be really nice if it can refer to value in API path as well. xD
Elixir is gaining more usage especially when it comes to building real time/multi-connected applications (via websocket). While there already is someone trying to support it, https://github.com/elitau/pact_elixir it doesn't support a lot of the critical features. Do you have any plans to implement one yourself or help out with the existing one to get it to a usable condition.
Webhook on pacticipant tag
I want to schedule the particular jenkins job on application deployment. Technically it's when the application is tagged with production tag, for now I just add hook on deployment process which is very hard, since I need to modify each deployment. For me, the most convenient approach would be just provide a webhook, when app has been tagged with production tag.