0

In a microservice architecture, it is common for an API Gateway to perform API Composition (providing CQRS is not used) for queries to multiple services to combine data to make it ready for a front end client. There are options for non-query distributed calls though, one of which would be to call one of the services from the gateway and then have the services call (send messages to, etc.) each other in order to create or delete a (distributed) entity, preferably using sagas.

My question would be, is it okay to make non-query (POST, DELETE, etc.) calls to multiple services from an API Gateway, similar to how we do the API Composition for data queries, and even abolish the services-call-each-other approach altogether? What are the pros and cons of such approach, and is it actually used (or frowned upon) in real production systems?

I draw a simplified diagram to better illustrate what we're comparing here.

diagram

Improve this question

1 Answer 1

Reset to default
0

In short, the more dependencies you have, and the more centralized your architecture is, the less independent and less maintainable your solution becomes.

If you develop your architecture from scratch, you would not have any need for an "API Gateway", because you would create services that work independently, as far as possible. Each service should be able to serve its use-case completely independently.

Normally in these cases the workflow might be defined by the server by providing links and forms, so the client can execute a workflow without it being hardcoded.

Second best solution to this is that services call each other. This is a hard dependency between services, needing coordination between development teams and a runtime dependency. Not good, but acceptable for some use-cases.

Worst solution is when a Gateway coordinates everything. Not only is it a hard dependency, but a central hard dependency on every service that contributes. It's a bottleneck organizationally and of course runtime. This may be necessary sometimes, but should be avoided if at all possible.

With all that said: I would go for solution on the right. That is, I would try to not leak use-case specific information into the Gateway. But as said, I would try really hard not to have an API Gateway in the first place.

Improve this answer
3
  • I have several additional questions. 1) If I understand correctly, you suggest using something like HATEOAS, but without the API gateway, meaning that clients would call the services they need and, if necessary, receive further request details in a HATEOAS fashion, right? 2) What if then it's impossible to get rid of the data distribution across the services, and you need to somehow combine data pieces in order to fulfill the request, which will probably be inefficient if done on front end? 3) Could you share some useful materials to read/watch about the gatewayless microservice architecture?
    – PolarBeaver
    Jan 20, 2022 at 20:27
  • 1) Yes. Hypermedia implies that nobody other than the server knows the workflow. I.e. you can't "orchestrate". Client only sees URIs, doesn't know or care whether that is the "same service" or not. 2) 3) Thinking about this is basically asking yourself how you would do it in HTML for people. When was the last time you couldn't design a web-site where the user sees everything relevant on the same page? I recommend thinking about services as web-sites rather than data sources.
    – Robert Bräutigam
    Jan 21, 2022 at 10:01
  • 1
    I would try really hard not to have an API Gateway in the first place. API Gateways are common elements of MS architectures, but they aren't a MUST as @RobertBräutigam is pointing out. API Gateways become essential when you manage APIs on large scale, APIs belonging to many and different contexts (or business scopes) within the company and you need to provide the company with a single entry point to this ecosystem of APIs. Entry point where to apply once all the security policies, documentation, availability, etc...
    – Laiv
    Jun 21, 2022 at 10:05

Your Answer

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

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