Native JavaScript provider support

[BenSayers]

As a JavaScript provider in order to validate a pact file I need to declare a dependency on the pact-provider-proxy gem and create a file written in Ruby to run the verification and change provider states.

I'd like to start a conversation about how native JavaScript support can be added. I'm imagining a similar setup to this consumer dsl, where the JavaScript layer is a thin wrapper around the Ruby implementation. Please add your thoughts on options available and what the first steps might be. I'm happy to contribute to this.

[bethesque]

I think this is doable.

On a side note, I've packaged the pact-mock-service using Travelling Ruby, and I have it on my backlog of tasks to publish the executables to npm so we can use it with node (look mum, no Ruby!). If you're a node person, maybe you'd like to look into this, because we'd want to do the same for the pact-verification task? The executables are here: https://github.com/bethesque/pact-mock_service/releases

We can package the verification code the same way. The complication here is setting up provider states. We have to provide a way for the ruby code to call out to javascript code, which you will need to set up the right data before an interaction is replayed. One way could be to call out to a shell script, which takes the provider state argument. The shell script would then be responsible, via the javascript tool of choice, for setting up the provider state. Another way would be to call a URL on the app that is only available during testing, with the provider state as an argument (this is how JVM pact verification works).

Thoughts?

[BenSayers]

I'll have a look into what you've done with Travelling Ruby when I next get a chance.

As for how the Ruby verifier and the JavaScript can communicate with each other - some concerns I have with shell scripts is they are not platform independent and force the client to write code in a language that isn't JavaScript.

A concern I have with the app hosting a URL approach is it forces apps to deal with the complexity of making sure this state change URL is not available when the app is not in testing mode. For some of the more critical systems I work on this would be a big concern as accidentally shipping the state change URL is a big security problem.

I think using http for the Ruby and JavaScript to communicate is on the right path - what if the JavaScript library we write spins up a server to facilitate this communication? The clients of the library then supply a node module which gives us a way to communicate the state changes. If the app hosting a url for state changes is a common use case we could make it easy to do this inside the node module the client supplies us.

The advantages are the clients get to stay in JavaScript, and have a lot of flexibility as to what happens when the state changes. From the perspective of the Ruby verifier, a http interface is very platform and language neutral which I think will make it easier when it comes to adding more languages. The disadvantage is that this library would have a dependency on node (is this a problem?).

[bethesque]

Using a "provider state" server sounds like a good idea. It could be a standalone package that is optional to use if someone does not want to use node. The ruby verification code just needs to know which base URL to hit to set up the state - it does not care whether it is the app under test or a separate server.

[BenSayers]

So what are the next steps in getting this going?

[bethesque]

I started to explain what we could do, and then I realised it would be easier to throw the code together and get you to look at it. Hopefully this is self explanatory, let me know if you have questions https://github.com/bethesque/provider-state-server-poc