API gateway vs. reverse proxy - nginx
In order to deal with the microservice architecture, it's often used alongside a Reverse Proxy (such as nginx or apache httpd) and for cross cutting concerns implementation API gateway pattern is used. Sometimes Reverse proxy does the work of API gateway.
It will be good to see clear differences between these two approaches.
It looks like the potential benefit of API gateway usage is invoking multiple microservices and aggregating the results. All other responsibilities of API gateway can be implemented using Reverse Proxy. Such as:
Authentication (It can be done using nginx LUA scripts);
Transport security. It itself Reverse Proxy task;
Load balancing
...
So based on this there are several questions:
Does it make sense to use API gateway and Reverse proxy simultaneously (as example request -> API gateway -> reverse proxy(nginx) -> concrete microservice)? In what cases ?
What are the other differences that can be implemented using API gateway and can't be implemented by Reverse proxy and vice versa?
It is easier to think about them if you realize they aren't mutually exclusive. Think of an API gateway as a specific type reverse proxy implementation.
In regards to your questions, it is not uncommon to see both used in conjunction where the API gateway is treated as an application tier that sits behind a reverse proxy for load balancing and health checking. An example would be something like a WAF sandwich architecture in that your Web Application Firewall/API Gateway is sandwiched by reverse proxy tiers, one for the WAF itself and the other for the individual microservices it talks to.
Regarding the differences, they are very similar. It's just nomenclature. As you take a basic reverse proxy setup and start bolting on more pieces like authentication, rate limiting, dynamic config updates, and service discovery, people are more likely to call that an API gateway.
I believe, API Gateway is a reverse proxy that can be configured dynamically via API and potentially via UI, while traditional reverse proxy (like Nginx, HAProxy or Apache) is configured via config file and has to be restarted when configuration changes. Thus, API Gateway should be used when routing rules or other configuration often changes. To your questions:
It makes sense as long as every component in this sequence serves its purpose.
Differences are not in feature list but in the way configuration changes applied.
Additionally, API Gateway is often provided in form of SAAS, like Apigee or Tyk for example.
Also, here's my tutorial on how to create a simple API Gateway with Node.js https://memz.co/api-gateway-microservices-docker-node-js/
Hope it helps.
API gateway acts as a reverse proxy to accept all application programming interface (API) calls, aggregate the various services required to fulfill them, and return the appropriate result.
An API gateway has a more robust set of features — especially around security and monitoring — than an API proxy. I would say API gateway pattern also called as Backend for frontend (BFF) is widely used in Microservices development. Checkout the article for the benefits and features of API Gateway pattern in Microservice world.
On the other hand API proxy is basically a lightweight API gateway. It includes some basic security and monitoring capabilities. So, if you already have an API and your needs are simple, an API proxy will work fine.
The below image will provide you the clear picture of the difference between API Gateway and Reverse proxy.
API Gateways usually operate as a L7 construct.
API Gateways provide additional functionality as compared to a plain reverse proxy. If you consider some of the portals out there they can provide :
full API Lifecycle Management including documentation
a portal which can be used as the source of truth for various client applications and where you can provide client governance, rate limiting etc.
routing to different versions of the API including canary/beta versions
detecting usage patterns, register apps, retrieve client credentials etc.
However with the advent of service meshes like Istio, Consul a lot of the functionality of API Gateways will be subsumed by meshes.
From HTTP: The Definitive Guide:
Strictly speaking, proxies connect two or more applications that speak
the same protocol, while gateways hook up two or more parties that
speak different protocols. A gateway acts as a "protocol converter,"
allowing a client to complete a transaction with a server, even when
the client and server speak different protocols.
In practice, the difference between proxies and gateways is blurry.
Because browsers and servers implement different versions of HTTP,
proxies often do some amount of protocol conversion. And commercial
proxy servers implement gateway functionality to support SSL security
protocols, SOCKS firewalls, FTP access, and web-based applications.
Reverse proxy, such as Nginx and Apache, do not deal with observability, authentication, authorization, service orchestration, etc., but only do load balancing and forward traffic to upstream.
API Gateway is close to the user's business scenario and helps users solve the security and observability issues of various APIs and microservices.
Different positioning leads to different technical aspects of reverse proxy and API gateway. API gateways, such as Apache APISIX, have nearly 100 plugins and support multiple programming languages for plugin development.
If you already have a good API gateway, there is no need to use a reverse proxy.
Regarding the Andrey Chausenko's answer that
I believe, API Gateway is a reverse proxy that can be configured dynamically via API and potentially via UI, while traditional reverse proxy (like Nginx, HAProxy or Apache) is configured via config file and has to be restarted when configuration changes.
I think it is not true nowadays as modern reverse proxy like Envoy can be dynamically configured by control plane via xDS.
Related
Micro Service with API Gateway Ocelot vs Nginx
I have a .net core based micro service architecture. I chose ocelot as api gateway. My frontend application is vue js based and hosted on nginx container. During a discussion today, I learned that nginx can already be used as a gateway.it was suggested that "you should use nginx for a gateway because you already use for serving frontend, nginx could deploying as a gateway too" I searched the internet to compare the two gateways (I know the main purpose of nginx is not a gateway) but couldn't find any information about their pros and cons like performance,scalability availability etc... Can someone who uses the 2 technologies share information with me about which one I should choose?
Ocelot is .NET API gateway but cloud agnostic. It has following features as mentioned in article here. It is a free simple Nuget package for simple installations and not too advanced features or performance requirements, but it beautifully does the job always in .net environment, and provides some features also. It is lightweight, fast, scalable and provides routing and authentication also besides all gateway features. On Azure, Azure API management provides these features plus many more advanced gateway features. NGinx has a open source version and a plus version. NGINX is a high‑performance, scalable, secure, and reliable web server and a reverse proxy. NGINX enables all the main web acceleration techniques for managing HTTP connections and traffic. For many years, NGINX capabilities such as load balancing, SSL termination, connection and request policing, static content offload, and content caching have helped NGINX users to build reliable and fast websites quickly and efficiently. NGINX can also act as a secure application gateway, offering a number of specialized built‑in interfaces to pass traffic from users to applications. So, as you see NGinx is much more than just an API gateway. With a server, you can integrate many other services like traffic distribution, policies, monitoring, alerts, notifications, custom configurations etc. Ocelot may have limited performance or configurability for an enterprise grade application. Nginx is a different software than Ocelot. Kong on NGinx is more popular software for API management gateway and is not .NET specific. If your company already is using it, and has it already for deployment, you should continue with Nginx. Ocelot vs Kong vs Azure API management vs Nginx In normal circumstances, Ocelot may appear better software than Nginx. But Nginx is a full fledged software. Few reasons: a. Your company has a license for Nginx plus already, why use another software for API management. b. Nginx is configurable for high performance, ocelot is not. If you use thread pool is nginx, performance can be tuned. Ten Nginx performance tuning tips.. You can do limited to none such things in Ocelot. It has its own bunch of open issues for a gateway. NGinx plus users will have training as well as team support already available. Nginx will be one API Gateway for all of Your applications (technology independent). Ocelot is technology dependent. Given the pros and cons, your company might already be having a Nginx plus license and a common API for multiple applications, and that's why they might be pushing for it.
First and foremost Nginx and Ocelot are very different software. using Nginx will eventually be good for your infra as it can be used as an API gateway and it's open-source, secure, and offers many other benefits. Using Ocelot will have disadvantages in long run. You'll need to handle one more software extra. Why would one waste time on that? and the developer will need to understand both of them. I suggest you go with Nginx as it's already implemented and do your work
Yes you can use nginx as a gateway. But Apache APISIX is even a better option to use compared to Nginx and Kong. I found this article helpful while searching for a better API Gateway option to use. https://api7.ai/blog/why-choose-apisix-instead-of-nginx-or-kong/
How to restrict Kubernetes Engine HTTP access to only Firebase apps
I currently have services running on the Google App Engine platform which use the X-Appengine-Inbound-Appid header to limit HTTP requests to our apps only. I recently found out that some of my services require a static IP and therefor I would like to move some of the services to the Kubernetes Engine. Is there a way for Kubernetes Engine to secure requests using a similar header approach? The requests should only be allowed from our own Firebase apps. Ideally I would keep things as simple as possible for the clients using the services. Possibly I could generate a specific API key for each user which can be blacklisted on abuse, but that already adds quite a bit of complexity.
You can use ngnix ingress controller as an entry point for your cluster, and add whatever rules for ngnix.
how to forward TCP requests through a reverse proxy towards multiple data services (Mysql, hadoop, Aurora, mssql ... etc)
I'm trying to solve an architecture design puzzle, it's about designing an infra for keeping data and servers as much secured/hidden as possible, here are requirements: I want to hide the internal design of my infra (several data servers with public and private hosts) I want to access to each service using same IP address, and the query is forwarded to right server based on something (cookie, uri, port or whatever) access to data service must be enforced with ssl/tls encryption After studying carefully these requirements I was thinking about using a reverse proxy and grant access to all data services only across the reverse proxy server, an other pro of a reverse proxy is that access authentication is enforced at once with sll/tls encryption and no need to configure each endpoint separately. my real issue is that I didn't find any reverse proxy that supports tcp queries, and same for static load balancing algorithms that are supported only for HTTP requests, (haproxy for instance) Any idea how to solve this issue ? Thanks to all
About service discovery and proxy
I am reading several articles about micro-service. At the server-side service discovery part, I am drawn to the Kubernetes and Marathon's style of running a proxy on each host/docker-container that functions as a server-side discovery router. By doing this, we can move all code coupled with service registration/discovery and circuit-breaker to that proxy. By configuring the router of each host/docker-container, the proxy can be transparent to the service and the network, and we can implement some gossip strategy to make the proxies sync their knowledge of the network. Seems like an excellent solution. Can anyone explain to me what are the drawbacks of doing this and recommend some open-sourced solution implemented such kind of thing?
Is it good to use ASP.net Web API as a Service Layer?
Myself and my architect are designing the architecture for one of our products and he suggested to go with Web Api as a Service Layer (because it's a light weight component). Straight away I'm thinking how it can be used for non-http based clients and also for external clients. How can we provide the proxy information about our API (in case the API is having a complex type as parameter)? Please advice whether we can use Web API as Service Layer?
Straight away I'm thinking how it can be used for non-http based clients Well, it can't. The Web API works only on top of the HTTP protocol. If you need to use some other transport protocols such as UDP you might consider WCF instead. How can we provide the proxy information about our API RESTful services do not have the notion of proxy information. They should be documented well for non .NET clients. For .NET clients you could share the contracts (Request/Response Dto) between your server and client application. The client application could then reuse those Dtos which may act as what you call proxy and which is something that exists in the SOAP world but not in the REST world.