Open bethesque opened 7 years ago
Having thought about this more, I remember that when I was going down this path a while back, I decided that duplication of information was bad, and that we should just store a link to the project repository, which should have (but probably doesn't, sigh) all that information.
I love this idea.
It does raise some other thought bubbles for me though:
metadata
section or even given a first class property?), and have the broker use this information, rather than have the broker as the source of truth for a pact?With respect to implementation options I believe that Option 2 is the best.
Aside from it seemingly crossing concerns and conceptually it might be best separated from the verification and publish processes, as you say it is the most flexible for when we add our (unicorn) UI. You can see a situation where this might be manually managed outside of a development lifecycle and so decoupling from the verification and publishing seems prudent. At the very least, it gives some flexibility in its usage.
This of course doesn't preclude client libraries from combining two calls to preserve existing workflow behaviour.
I guess my fear of having it decoupled from the publishing/verification cycle is that information left in any repository gets outdated. I can imagine a dev modifying a pact and then going, oh wait, that info in the pact publishing task it outdated, I'll update it and commit it now. Until we get a nice UI, I can't see people looking at the info in the broker and then going, that's out of date, I'll just open up the HAL browser and update that information.
If we try and do a middle ground of putting the info in the publishing config, and update it in the pacticipant resource each time, we'll just end up overriding any manual changes.
Having just joined a client company with an existing broker with a heap of pacts, I realise how much more benefit could be gained by publishing contact details for each pacticipant. These details would be included in the HTML view of each pact.
(similar config for provider)
Option 1. Include details with every pact/verification
Pro: no separate call Con: can only update info by publishing a pact/verification. If provider is not verifying pact, then provider details cannot be added.
Option 2. Add information to the pacticipant resource
Pro: can update directly via API/UI (if/when we build a UI) Con: need to add new call to all publishing clients and ensure they all PATCH the info. But how do they know when to update? Should the config in the code overwrite the server? Gets messy.
Other design considerations
@uglyog @mefellows @neilcampbell your thoughts would be appreciated