What is the most appropriate way to launch an API gateway on a massive domain?

Question

We're trying to develop a comprehensive system which has broken down to multiple microservices. So we decided to use CQRS and DDD to tackle the complexities of the domain. Also we’re about to launch Generic Domains (e.g. Authorization, Tracing and Logging) to minimize the size of microservice.

Everything goes fine until we discussed about the form of the API Gateway. There is a cross-road: Simple reverse proxy or a specific API which needs more efforts and collaborations between developing teams.

The question is what is the risk of using a reverse proxy when you’re unable to use a BFF(Backend for frontend) in this case and also is there any turning point when we face with the deadlocks?

For instance, you’re going to have multiple client apps (web app and mobile app) and there are thousands of APIs which should be used in different ways. In addition, when you route the request to the exact API synchronously, you may disregard the Command fact of CQRS paradigm.

Developing

The technologies that we use to develop our Microservices are .net core, rabbitmq, open-tracing, mssql and dapper. We develop the APIs through different teams with individual repositories and mono-repositories for the management app and users’ dashboard app with Angular.

Deploying

We build docker images in our CI/CD pipelines and infrastructural services to ensure the deployment team about the production environment functions. Both APIs and client apps deploy independently in different docker swarm stacks.

Answer 1

tbh I'm still not 100% sure what you are asking. But I'll give you a general answer on the topic of exposing APIs for use when you have a "massive domain" by which I take to mean, you have lots of microservices for various parts of your business.

1. "API Gateway" is a generic term that has no "official" meaning.

2. You don't need an "API Gateway"

   You can add authentication and load balancing to each service and have them called directly. The reason for adding an API gateway is to move some of the common stuff, ie authentication off the microservice. This simplifies your microservices and perhaps allows you to use alternate technologies such as hosted lamdas.

3. You can use a reverse proxy as an API Gateway.

   In this case you can probably only do the load balancing and networking side of things, rather than authentication. But it allows you to collect all your apis together under one url and simplifies them to an extent.

4. None of this helps with the amount of logic required in the client or calling application.

   From the client's point of view you still have the same number of endpoints. Nothing has really changed except maybe the url

5. A "Backend for Frontend" approach allows you to move logic from the front end or calling application to the backend as an additional api

   This API will call all your lower level APIs and hide the complexity from the front end.

   This is mainly done to simplify the javascript for those poor front end devs so they can concentrate on choosing nice colours and making sparkles follow the cursor etc

   But it also can be used to hide 3rd party api calls, secret keys, admin functionality etc etc. Generally its a good idea

6. You can keep adding APIs forever. You dont really hit a "deadlock"

   The more complex your system, the more complex the orchestration of it true. But APIs, API gateways, reverse proxies, BFFs etc can all be used at the same time for their various purposes and not conflict with each other.