Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidance and documentation needed to differentiate between event messages and command messages? #104

Open
danmalcolm opened this issue Aug 9, 2023 · 1 comment

Comments

@danmalcolm
Copy link

There are 2 common messaging collaboration patterns that might be used between 2 services and verified by contract tests.

  1. Service A consumes an event message published by Service B. The event message schema is part of Service B's contract and Service A would be said to depend on Service B in this context
  2. Service A sends a command message to a queue consumed by Service B. The request message schema is part of Service B's contract. Service A is making use of the functionality of Service B to do its job. It is very similar to a typical HTTP API request. Service A would be said to depend on Service B in this context

The Pact documentation (https://docs.pact.io/getting_started/how_pact_works) seems to fit the event message collaboration pattern well:

  • Consumer: An application that makes use of the functionality or data from another application to do its job. For applications that use HTTP, the consumer is always the application that initiates the HTTP request (eg. the web front end), regardless of the direction of data flow. For applications that use queues, the consumer is the application that reads the message from the queue.
  • Provider: An application (often called a service) that provides functionality or data for other applications to use, often via an API. For applications that use HTTP, the provider is the application that returns the response. For applications that use queues, the provider (also called producer) is the application that writes the messages to the queue.

However, any user looking for guidance on how to add tests for a command message interaction might be confused by the above. From a dependency point-of-view, you would intuitively view the service (Service A) that "calls" the other service as the consumer (similar to an HTTP API call) and the service that owns the message contract (Service B) and does the work requested in the command message as the provider. However, the documentation above states very clearly that the service that reads messages from the topic should be the consumer, which is the opposite!

This has been summarised well in a blog post - https://dev.to/frosnerd/message-pact-contract-testing-in-event-driven-applications-1aej (see the "Message Pact and the Command Pattern" section). This also suggests how to work around it to more faithfully reflect the dependency direction.

It would be useful to understand how the designers of Pact would view the provider and consumer roles in a command message collaboration scenario. Should the provider be based purely on who is writing the message, or should it be based on who defines the message contract? Some guidance in the documentation either way would be extremely useful.

@YOU54F
Copy link
Member

YOU54F commented Aug 9, 2023

Hey @danmalcolm

Thanks for the link, I'm looking forward to reading that

We have these links around message pact

https://docs.pact.io/getting_started/how_pact_works#non-http-testing-message-pact

when it was first introduced in V3

v4 spec allowed for synchronous and asynchronous message types, as well as http, also allowing these to be combined in the same pact file.

Some info around why the spec came to be

https://docs.pact.io/blog/2022/05/04/pact-open-source-update-may-2022#v4-pact-specification

and a bit more of a background of the history and where things are moving to

https://docs.pact.io/blog#pact-proliferates---lead-by-example

I'll look to absorb and answer your points in time. We are really open to improving both our terminology, examples and documentation around EDA based systems, so love to collab

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants