pact-specification
pact-specification copied to clipboard
pact-foundation
Introduce message queue support
Since the approved spec for v3 is here and it includes messages support, a possible support for message queue protocols should be made.
There should probably be a factory for that, which would make different queueing protocols possible to implement and use. In example, AMQP, NATS, etc.
The only work done in this area is with the JVM version and the Rust shared library. The idea with the shared library is that that can be used in other language implementations (JS, Ruby, Python, .NET, etc.)
As discussed with @mefellows I'd (my employer) be willing to help with NodeJS version that supports RabbitMQ and gRPC on top of the HTTP that exists already. We're not a Ruby shop so would prefer JS
FWIW the current strategic implementation of this would look something as follows:
- Complete the v3 specification in Rust (both consumer and provider) - this is ~70%+ complete
- This implies design work on how the interaction between the client and native library is completed
- Refactor JS / other implementation DSLs
- Embed shared library into implementations, starting with JS
Hi all,
I'm pleased to announce a bit of an update on this:
- We now have a shared Ruby package with the minimal v3 implementation required to make messages (and other async things) work
- We have beta versions of Pact JS and Pact Go with working examples
We'll be rolling these into all languages over the coming months.
cc: @gerrymcgovern1
Can you answer, please? When you will start and finish implementation of pact-v3 for php(approximately)?
We don't have specific dates, and we've already indicated approximate timelines. You could reach out to the contributors on pact php directly. Even better, help with it's development?
You'll need to reach out to the python library maintainers to let them know you're interested. The underlying code is done in the shared library.
Hello, Does Spec v3 support MessageQueue for PACT Java? I saw that she no longer has the @PactVerification annotation that calls the build method for message consumption.
Yes, Pact JVM definitely still supports messages. There are a few examples in the github repository
e.g. https://github.com/DiUS/pact-jvm/blob/master/consumer/groovy/src/test/groovy/au/com/dius/pact/consumer/groovy/messaging/PactMessageBuilderSpec.groovy and https://github.com/DiUS/pact-jvm/blob/master/consumer/junit5/src/test/java/au/com/dius/pact/consumer/junit5/AsyncMessageTest.java and
Does the specification support routing keys in any form? Ex. RabbitMQ would require specifying the destination exchange and routing key separately.
Yes, it supports it via metadata (otherwise we'd need queue specific fields in the spec, which is not ideal). You'll need to look at the language specific docs for how this is done.
Yes, it supports it via metadata (otherwise we'd need queue specific fields in the spec, which is not ideal). You'll need to look at the language specific docs for how this is done.
What happens if we use pact to integrate 2 different language application? Shouldn't there be a language agnostic way to specify destination between services?
Yes, of course! The specification has them stored in the metaData field of the output contract. But that doesn't help you work out how to get it in there in the first place.
Each language has its own way of doing this (and not all languages support message pact).
e.g. in Pact JVM: https://docs.pact.io/implementation_guides/jvm/provider/junit/#example-of-message-test-that-verifies-metadata
Closing now as message async/sync message support available in v4
Users can create their own plugins using the pact plugin framework to cover transport and matching semantics for specific protocols
https://docs.pact.io/plugins/quick_start
There are some existing plugins available
https://docs.pact.io/plugins/directory
and some have been created by users for in-house use only (not open sourced)
for implementations in respective languages, please see their repos and raise an issue if it is not implemented.
please also be aware that we are open source maintainers, so the best way to get it implemented, is to do it yourself!
People will be happy to guide, so just reach out.
Asking when something will be done, will probably not get you very far :)
