Introduce message queue support about pact-specification

[TimBailey-pnk]

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

[mefellows]

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

[mefellows]

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.

[mkozjak]

Any progress here?

[bethesque]

Sorry @mkozjak, none that I know of.

[uglyog]

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.)

[mefellows]

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

[gerrymcgovern1]

Any update on this?

[arkonchik]

Can you answer, please?
When you will start and finish implementation of pact-v3 for php(approximately)?

[mefellows]

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?

[arkonchik]

Thanks for reply

[singlaive]

Any news?
Any progress on Python?

[bethesque]

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.

[klyff]

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.

[mefellows]

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

[EvgheniiShipilov]

Does the specification support routing keys in any form? Ex. RabbitMQ would require specifying the destination exchange and routing key separately.

[EvgheniiShipilov]

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?

[mefellows]

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