Closed mkozjak closed 4 months ago
Any progress here?
Sorry @mkozjak, none that I know of.
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:
Any update on this?
Hi all,
I'm pleased to announce a bit of an update on this:
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?
Thanks for reply
Any news? Any progress on Python?
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 :)
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.