Proposal: Provider Actors

[maxlinc]

Consumer Actor Adapter

The roadmap for Pacto v0.4.0 will shift towards a more hexagonal or "Ports and Adapters" architecture. One of my planned adapters is Actors - in the sense of "courtroom re-enactments".

The Provider Actor adaptor type will drive the provider responses.

Responsibility

The Provider Actor is responsible for creating responses to Requests which have been generated by the Consumer Actor.

This is less open-ended than the consumer actor. It will always receive a Faraday::Request and is expected to create a Faraday::Response. See the notes on Consumer Actor about why I think we should use Faraday::* for objects that represent actual HTTP transactions rather than abstract templates and rules for the service.

Concrete Implementations

Currently we have two concrete implementations that should be refactored to match the pattern:

• JSONGeneratorProviderActor - creates a response based on the JSON schema. This is current behavior when Pacto is stubbing.
• ExampleProviderActor - Creates a response based on an example. I propose this as the new default behavior for Pacto stubbing, taking advantage of the example section of the new Contract schema.
• LiveProviderActor - Proxies the request to a real service endpoint, either the actual provider or an out of process stub server like Mountebank or Mimic.

Proposed Adapter Interface

# Generates a response for the service
# @param contract [Pacto::Contract] the contract describing the service.
# @params request [Faraday::Request] a request ot respond to
# @return [Faraday::Response]
def react(contract, request)
  # respond
end

Proposed Port Locations

This should take the place of Contract#stub_contract! and Contract#provider_response.

There should be a default Provider Actor set at the top-level (Pacto or Pacto::Configuration) or "prosecutor" level, just like with Consumer Actors.

[maxlinc]

Example actor added via #118.

Close - split LiveProviderActor to #143.