Document ideas for how to deal with API Gateway

[bethesque]

Background conversation:

A 11:32 AM
To that specific example, we’ve hit similar conceptual problems with a client. I expect that there’s an API gateway which is a single deployment unit, and it fronts two services, which are also separate deployment units. I think they’re asking about a contract to the gateway, which is defined by two swagger documents (only)

B 11:35 AM
That situation may have more nuance to it. If the gateway is just a pass thru, then for the purposes of contract testing I may likely pretend like it doesn’t exist in the first place and have separate contracts with the target APIs

A 11:35 AM
Yep.

B 11:36 AM
Otherwise, the gateway tests are going to have to do a lot of mocking and not a lot of useful things. It gets messier if the gateway does more than a gateway should - orchestration, re-mapping paths etc.
11:36
I still tend to avoid contracts with a gateway, but to be fair, haven’t encountered situations where that may genuinely be necessary

A 11:37 AM
What do you think of the path rewrite per service pattern? Where a gateway accepts /users/whatever, and redirects that to /whatever on the users service?

B 11:45 AM
Pretty standard for gateways to do that, and quite easy to deal with.
Have the consumer configure the path (possibly least optimal)
Have the provider re-write the path during verification, knowing how it is mapped behind the gateway
2 - can be done in multiple ways: re-map the paths in the app, little proxy in front of it or request filters (edited)
👍
1