Skip to content

Document ideas for how to deal with API Gateway #8

Open
@bethesque

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions