0

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.

New contributor
Nima Boobard is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
  • 2
    im unclear on what the exact issue you are concerned about with a reverse proxy is? – Ewan Aug 14 at 15:22
  • The first one is the complexities of using multiple API requests to get a business done. For instance, client should request AddOrder from OrderService then request CreateBills from PaymentService. If there isn't any aggregation between services, the client should be aware of consequence services to be requested. Now imagine you have more than one client app and the APIs should be requested as the same. – Nima Boobard Aug 15 at 9:35
  • i don't see how that relates to an api gateway/reverse proxy. Sure your api is complex with mutiple endpoints and the client has to call it correctly. But that's true regardless of whether you use an api gateway? – Ewan Aug 15 at 9:43
  • 1
    are you really asking about using a BFF to aggregate those calls into a simpler API designed for a specific front end vs exposing all the APIs and putting the aggregation logic in the client? – Ewan Aug 15 at 9:45
  • Yes, exactly. According to msdn articles about API gateways, Aggregators solve this problem. That means you cant't deploy your independent api and do nothing about the coupling logics. – Nima Boobard Aug 15 at 9:51
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.

  • Thanks Ewan. These are good points 🙏 – Nima Boobard Aug 16 at 7:56

Your Answer

Nima Boobard is a new contributor. Be nice, and check out our Code of Conduct.

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.