You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When writing a Pact test, a provider needs to specify a source for contracts using annotations on the test. The source can be either a local directory, or a broker. It's awkward to have to change the annotations to switch from the broker to running locally. This feels like the sort of scenario where a dev service might be useful.
It's not trivial, though, because a dev service would need a source of 'real' contracts.
We could either:
Cache contracts when running with the broker, and then use them in offline mode
Configure a dev service to point to a local source of contracts
The second option works great for demos, but I'm not sure how useful it would be for realistic development.
The first option may be more useful, but it's not a perfect fit for the semantics of a dev service. Normally we'd configure credentials for production, and not for dev, and then a dev service would be invoked. Here the behaviour change wouldn't be prod vs dev, but online vs offline.
The text was updated successfully, but these errors were encountered:
If the consumer and provider are on the same machine (which is most likely for demos, but could happen in exploration scenarios too), we can publish to the broker from the consumer, using instrumentation. The consumer should only attempt to publish if it detects a broker. It should use similar testcontainer sharing logic as the kafka dev services do.
When writing a Pact test, a provider needs to specify a source for contracts using annotations on the test. The source can be either a local directory, or a broker. It's awkward to have to change the annotations to switch from the broker to running locally. This feels like the sort of scenario where a dev service might be useful.
It's not trivial, though, because a dev service would need a source of 'real' contracts.
We could either:
The second option works great for demos, but I'm not sure how useful it would be for realistic development.
The first option may be more useful, but it's not a perfect fit for the semantics of a dev service. Normally we'd configure credentials for production, and not for dev, and then a dev service would be invoked. Here the behaviour change wouldn't be prod vs dev, but online vs offline.
The text was updated successfully, but these errors were encountered: