Suggestions about how to deal with self-hosted API gateway or proxy containers

[jillesmc]

Question

How would you suggest dealing with API Gateways like Kong or with smart proxy systems that forward the requests to other systems but do some magic before forwarding?

In my use case, I have a Kong API Gateway in front of a bunch of microservices. I'm representing the API gateway as a Container because they all are part of the same Software System.

In a more complex scenario, I have a microservice responsible to deal with sensitive user session information, and this microservice also forwards the requests to other specialized microservice.

Something like:

Person -> front-end -> BFF -> external kong API gateway -> session microservice -> other specialized microservice

*The front-end and BFF are hosted outside the company.

I also have internal communication through an internal Kong API gateway. Like this:

microservice -> internal kong API gateway -> other specialized microservice

To make things more complex, I should say that the API Gateway has a relationship with containers that acts like middleware.

A dynamic representation of this flow would be like this

1. microservice -> Kong API gateway
2. Kong API gateway -> middleware microservice (this happens before Kong API gateway forwards the request to the destination)
3. Kong API gateway -> destination

These type of containers acts as some kind of hub for other containers and things start to get messy because the relationships lose their meaning when passing through the hub. :(

[jillesmc]

In your book, I read an example related to Components and the Logging component, but it is a little bit different here.

I would like to use the API gateway and its relationships in Dynamic diagrams, so I think I should not omit the relationship between micro-services and the Kong API Gateway.
It is a constraint that Dynamic relationships allow overwriting only pre-existent static relationships. Right?