Hello folks! The documentation states that “<Pact...
# pactflow-ama
m
Hello folks! The documentation states that “Pact may not be the best tool for testing pass-through APIs like BFFs”. I can understand the reasoning behind that, but as almost all FEs I’ve seen in the past years (mobile or Web) talk to the BE via some Gateway, how can we use Pact in the FE to ensure that the contracts between FE and BE are in sync? What kind of pitfalls would I fall into if I decide to add Pact between my FE (mobile and web) and my GW, and another one between my GW and the actual BE service? Thank you for your thoughts!
j
I guess the question I would want to ask in return is: what do you expect to test in the gateway? If you gateway is providing caching, basic auth, load balancing, or any other service which does not modify the payload itself (save maybe through some headers/logging which don't matter to the interaction itself), then the gateway is really not a party to the interaction and therefore need not be a party to the interaction anymore than the routers along your network need to be included. Hypothetically, if you do have two contracts (FE⭤GW and GW⭤BE), then when the FE adds a new interaction, you'll need to: 1. Update the GW as a provider to the FE to respond to the new interaction. 2. Update the GW as a consumer of the BE to add the new interaction. 3. Update the BE as a provider to the GW to respond to the new interaction. Steps (1) and (2) seem redundant in cases where the GW is simply passing through the payload.
m
Hey Joshua, your response aligns with my thoughts, so it’s reassuring to know I’m not too far off track. In our case, the GW is mostly doing authorization, but in some cases, it can act as a BFF to aggregate some calls to multiple BEs into just one call from the FE. Thanks for your thoughts!
j
In cases where it does aggregate calls, then I can see there being a benefit to a contract existing to ensure the aggregation does not break any existing interactions. Admittedly, this does become quite nuanced and I guess you would need to weigh up the pros and cons of having the GW as its own consume/provider. You could even mix-and-match to some extent: • FE ⭤ BE1 (for passthrough) • FE ⭤ BE2 (for passthrough) • FE ⭤ GW + GW ⭤ BE1 + GW ⭤ BE2 (for aggregates) This in itself is of course more complex, and you would need to decide what makes most sense within your ecosystem.