Hey all! I've been prototyping a process for the pact provider verification for my team's FastAPI service, and my team is pretty excited about it, but our architect is worried that it's a little complicated and introduces too much new stuff and the average developer will have a hard time understanding how it works and how to implement it (which is valid and I pretty much agree with him), so I thought I'd hop on here and see if anyone had any tips or thoughts about best practices for implementing the pact provider verifier in FastAPI. So first of all, the way I have it designed now is that inside the project repository's

./tests

directory I added a

pact_provider

directory to projects which are pact providers and a

pact_consumer

directory to projects that are pact consumers, with the idea being that the pytest tests which generate the contract live inside the

pact_consumer

directory and the start-up logic for running the server in pact-verification mode lives in

pact_provider

. (As best as I can tell, FastAPI needs a separate starting point to run the provider server in "pact-mode" because it has to add an extra router to define the

"/_pact/provider_states"

endpoint, via this example). We use poetry to manage dependencies and run the code, so in our

pyproject.toml

alongside the

start = "<app_name>.run:start"

script, I'm defining

start_pact_verifier = "tests.pact_provider.setup:run"

. So in order to implement this solution, a developer has to add: • the

start_pact_verifier

script line to their

pyproject.toml

• the

./tests/pact_provider/setup.py

file with a run method which imports the main application's

FastAPI

instance and adds the pact states router to it • the new pact states router itself, including the mapping of state strings to setup functions • plus the setup functions themselves It just seems like a lot to ask a developer to understand, and I was wondering if anyone had any tips to simplify it. Is there a way I could maybe utilize an internal poetry library to hide a lot of this boiler-plate away from the developer trying to implement this? Or maybe just a better design pattern I could be taking advantage of? My architect recommended moving the

run

function to the

<app_name>/run.py

module, but that seems like a pretty small step.

How were you thinking of "getting" the pacts? I mean if the developers will be involved in the process with the consumers, to come up with the expected behaviour and the different states - I think that all helps with the context of why this things is being added and how it relates

We are using pact broker to store the pacts, and we have a jenkins job which does the verifications which you can pass either the url of the pact you want to verify (we use this with the pact broker webhook) or you can pass it an environment name and it'll run the verifier CLI against all the pacts in the pact broker tagged with that environment

I mean the less technical part, if the FastAPI devs are talking with the consumer devs to go through the process of "we would like a new endpoint to do x" vs "there's an updated consumer Pact, we need to implement what they asked for"

Sure, I think initially it's going to be the same developers who own the consumer and the provider, because the intra-team contracts are going to be the easiest to spearhead

it probably helps if you have difficulty now 🙂 for us it was a case of yes it's adding in boilerplate, but previously a lot of very similar activities happened but the end result was some half baked json with a few notes in JIRA that invariably didn't actually turn out to be the final result so we were then doing something quite similar, just within a defined structure 🤔

Okay, I have an idea of how I might use a private library to handle a lot of the boilerplate code so developers just have to pass a FastAPI instance and their state function map

cookiecutter is still on my list to check out, i wonder if that would work for ongoing adding in additional changes beyond the first cutting 🤔