2
votes

I've recently started creating an application using the microservice architecture, as the app evolves the line that divides the concepts of a reverse proxy and an API Gateway fades for me:
I want to use nginx to handle load balancing & reverse proxying, but I also want to use an API Gateway so the clients don't know every microservice in the architecture, (among other things).

So now I'm stuck with the chicken & the egg issue, I've been thinking about what comes first :

  1. Request > API Gateway > nginx.
  2. Request > nginx > API Gateway.

I tend to think its number 1 but in that case, nginx wouldn't be the entry point of the application... (is that a problem?)

2

2 Answers

0
votes

API gateways comes with lots of features like throttling, cache, cors etc. Many use API Gateways to call different micro-services and combine the result at API Gateway level (I do not prefer it though). You can also do API version management with some of the API gateway tools.

Load balancing should come only after you have decided which API to call or block that API or which version of the API to call.

So option 1 looks right to me.

0
votes

Ideally you should opt for option 2. Here is why:

  1. API gateways are generally not designed to handle a potential DOS attack, having nginx infornt of your gateway removes that worry from mind.

  2. Most API gateways are route based, if you opt for subdomains, option 1 will only work with some gateways but 2 will work for all.

  3. A reverse proxy like nginx is built with performance in mind, and can handle more requests at lesser costs. Having a Node.js infront of a much higher performant server is a bottleneck!

An API gateway is technically a "specialized" reverse proxy. So eventually you will realize tasks can be performed by either .