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
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.
Plugin - Kafka
Kafka is emerging as a standard for sharing business events across the Enterprise. First class connectors for Kafka, and also integration/consideration for the Avro schema registry would simplify adoption.
Plugin - GraphQL
Creation of a GraphQL plugin that is aware of the syntax and semantics of a GraphQL client call (the provider response is standard JSON over HTTP). Whilst GraphQL is currently supported by Pact (see https://pactflow.io/blog/contract-testing-a-graphql-api/ ) users need to be aware of the HTTP abstractions and JSON payload of GraphQL, and to handle the query either: a) ensure the consumer payload matches exactly character-for-character what was expected, or b) use an ugly regex to allow additional spaces/characters in the query
Plugin - Websockets
Websockets is a popular transport for real-time and bi-directional communication between clients and servers.
Get latest provider version for a specific environment
Currently there is no way using the new environments approach to get/describe version within a specific environment. As a workaround I have had to use legacy tagging and create a version tag immediately after we record-deployment into an environment. I can then use this version tag when I describe version with the specific tag passed in. Seems there is a gap here between what you can do with legacy tags and the new environments approach. My reason for needing to do this is because I reached pact nirvana for one service, and now when I add new services, pact can-i-deploy fails on the new services as they are not fully setup with recording deployments/releases etc yet, so I was advised in Pact Foundation slack workspace as a temporary workaround to instead run can-i-deploy against specific pacticipants and versions until the other newly added services are ready too. For example, with a version tag I can do pact-broker describe-version -a ProviderService -l $TAG -o json | jq '.number' But there is no similar approach using environments approach instead of legacy tags.
Allow Pact generation in Android Automation tests
Description of the feature request: This feature request proposes the ability to generate pacts off the back of Android automation tests that utilise a mock server. Use case / for what or how I would use it: OkHttp provides a MockWebServer to which a Dispatcher can be added. This MockWebServer, is as the name describes, a mock instance for receiving responses when running automation tests. The Dispatcher that is provided gives developers access to both the request that is made as well as the response that they are expecting. Given these two pieces of information, we could create pacts. There are caveats with this suggestion however, and I don’t claim to have the answers. One of the blockers that stand out for me would be the mechanism of pulling the pact files to a project directory - the generated pacts described above would be stored on the device during automation tests. I propose this feature after observing the overhead required to write pacts that cover each permutation that a request can take for a given endpoint. Considering that this information could already be available to developers when they introduce Pact to their project, this could make Pact adoption much easier.
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.