Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple providers with shared consumers #41

Closed
ma499 opened this issue Sep 5, 2017 · 2 comments
Closed

Multiple providers with shared consumers #41

ma499 opened this issue Sep 5, 2017 · 2 comments

Comments

@ma499
Copy link

ma499 commented Sep 5, 2017

In our platform we have the concept of an 'adaptor' microservice to intermediate between each 3rd party providing the same capability. All adaptors are required to provide (shared) consumers with a consistent external contract - the mapping to each 3rd party is then isolated within each adaptor.

What's the best way of using Pacts to test the same contract against each adaptor? Our initial ideas are below.

  1. We could make our consumer Pact tests aware of each producer (adaptor). The tests could iterate through each adaptor, generating multiple Pact files, or we could modify the Pact implementation to generate multiple identical pact files given an array of producers. This has the downside that we have to modify our consumer(s) source (albeit trivially) when we add a new adaptor. Not great as we want to scale to ~200 3rd parties.

  2. Use something other than Pact. We could validate the adaptor against our Open API spec, potentially as part of run-time monitoring. In that case we would then run consumer Pacts only against a stub or template implementation of our adaptor, which is auto-generated from our Open API spec.

Any other ideas?

@uglyog
Copy link
Member

uglyog commented Sep 5, 2017

Atlassian have built a tool that can verify pact files against a swagger (or Open API) spec. See https://bitbucket.org/atlassian/swagger-request-validator

@bethesque
Copy link
Member

bethesque commented Sep 18, 2017

At a scale of 200 consumers, I don't think pact is the best option. Its purpose is to allow the consumers' requirements to drive the provider implementation, and to allow rapid changes with confidence to the provider, avoiding the traditional versioning approach. It's sweet spot is internal APIs. With 200 consumers, you're basically a public API, and you're going to have to provide stable versions, and move at a slower pace because there's no way 200 codebases will be able to keep up with rapid change. Driving out the requirements will be more of a long winded people process rather than a "lets have a quick chat and whip up a potential contract" kind of process.

@ma499 ma499 closed this as completed Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants