0

Our team had a discussion about the use of an API Gateway when our on-premises applications have to do a external HTTP call.

The scenario would be very simple:

On-premises application --> API Gateway --> Destination

We already have an API Gateway instance that handle incoming requests from clients, so the current API Gateway instance deal the following scenario:

External client (a partner) --> API Gateway --> Our on-premises applications

Now, about using one to handle calls TO (not from) external applications, the API Gateway would act like as simple as a proxy, just routing the request to the destination application.

One of the benefits of this approach is the traceability of the request, since our API Gateway offers rich trace and analytics as well as notifications about when a back-end is offline. Also, it's not costly to develop these interfaces at the gateway - few clicks can do it.

Personally, I think this is a good idea as far as we separate the 2 gateway instances, i.e. the current API Gateway instance will handle only incoming requests and we setup a new instance to handle this new scenario:

Current API Gateway instance (public instance):

External client (a partner) --> API Gateway --> Our on-premises applications

New API Gateway instance (internal instance):

On-premises application --> API Gateway --> Destination

I'd like to read another suggestions about this scenario. Is there a better way?

2
  • What benefits do you see for having two gateways instead of one?
    – Mat
    Commented Jul 6, 2021 at 20:51
  • @Mat If our public API Gateway suffer from a DDOS attack (which we already suffered), our internal API Gateway would be intact, this is one of the benefits, also, the governance, in my opinion, is easier when you don't mix concerns.
    – Matheus
    Commented Jul 6, 2021 at 20:56

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.