Pact Foundation

Hello, i have a question about how to handle a certain usecase/design philosopy for the broker in particular in regards to a mobile app. Not sure if i should use this chat or pact-broker

image.png

assume the following situation (there can be more teams and api's but that is out of scope for now)

Basically we are wondering since the mobile app contains multiple apis (which we chose to represent as seperate consumer - provider pairs) how to remove the  env prod from all of those pairs (since they are part of the same (mobile) app, once that appversion gets deprecated

seems like the unrecord/undeploy command only works per consumer-provider pair and not for the 'whole' broker

The undeployment says “version `xyz` of application `A` is no longer in production. So any check using selectors that checks for breaking `deployed-or-released` consumers would exclude that pact.

But for mobile, you would usually use `record-support-ended` which does the same thing, except with releases it leaves the other apps in `production` still in tact.

Perhaps you could show the selectors / `can-i-deploy` args?

>  (which we chose to represent as seperate consumer - provider pair
I’m not following the different consumer/provider pair thing you’re saying.

Are you saying if the mobile app speaks to 3 apis, you actually have something like:

```mobileAPI1-API1
mobileAPI2-API2
mobileAPI3-API3```
Instead of

```mobile-API1
mobile-API2
mobile-API3```
?

The answer is the same, except you need to do it  for each version of your mobile “consumer”

&gt; Are you saying if the mobile app speaks to 3 apis, you actually have something like:
I guess the answer is yes, however in your example with

```mobile-API1
mobile-API2
mobile-API3```

would this not also translate in 3 rows in broker (consumer-provider pairs)?

> If so, why did you do this?
Honestly could be a case of wrong interpretation of best practices.
I guess the answer for these unique consumer names is that in practice a different mobile app *team* is responsible per api

&gt; would this not also translate in 3 rows in broker (consumer-provider pairs)? (edited)
yes, it should

The application (or “pacticipant”) should be modelled on the thing that gets uniquely deployed (or released)

So if you logically release a mobile app to the app store, it should be modelled as a single pacticipant in PactFlow.

Splitting it into multiple is just going to make things more complicated, and is probably why the workflow is feeling complicated/confusing