1. Overview
In this tutorial, we’ll learn how to use HAProxy as an API Gateway for routing and rate limiting.
2. HAProxy as an API Gateway
An API Gateway is an application that sits in between a client and multitudes of backend services. It acts like a reverse proxy. It routes the API calls to the respective service. Also, it has the ability to take up a lot of responsibilities, such as securing the services, rate limiting the API calls, monitoring the traffic, and sometimes load balancing.
HAProxy is an open-source software load balancer and application delivery controller. It’s highly efficient and widely used in the industry.
In the upcoming sections, we’ll configure HAProxy such that it’ll act as an API Gateway.
3. HTTP API Routing With HAProxy
One of the major responsibilities of an API Gateway is to route HTTP requests to the destination servers. We’ll begin configuring HAProxy such that it starts routing HTTP requests based on their path, source domain, and data format.
3.1. Basic Configuration
The basic configuration of HAProxy is to be a load balancer. We’ll define the frontend and backend for the example:
frontend haproxy_as_api_gateway
bind 127.0.0.1:80
default_backend load_balancing
backend load_balancer
server server1 127.0.0.1:8080
server server2 127.0.0.1:8081
We’ve two servers that will be used for load balancing. The client-side application will resolve the request at 127.0.0.1:80. From there, HAProxy helps to route to the available server as we’ve defined a backend load_balancer. This backend sits on top of two servers that resolve at 127.0.0.1:8080 and 127.0.0.1:8081.
We’ll add further configuration to make it work like an API Gateway with respect to the use cases.
3.2. Segregating Requests by Path
The basic function of an API Gateway is to route the HTTP API calls to the respective services in a microservices architecture.
Let’s consider we’ve given two endpoints for our online store to a client application. One takes the order at the endpoint 127.0.0.1:80/order. The other manages the invoicing at the endpoint 127.0.0.1:80/invoicing.
For these two endpoints, we’ve deployed two separate microservices. The order service resolves at 127.0.0.1:8080, and the invoicing service resolves at 127.0.0.1:8081.
Here’s the configuration:
frontend haproxy_as_api_gateway
bind 127.0.0.1:80
acl PATH_order path_beg -i /order
acl PATH_invoicing path_beg -i /invoicing
use_backend order_service if PATH_order
use_backend invoicing_service if PATH_invoicing
backend order_service
server server1 127.0.0.1:8080
backend invoicing_service
server server1 127.0.0.1:8081
In this configuration, the path /order will always be resolved at the backend order_service. Similarly, the path /invoicing will always be resolved at the backend invoicing_service.
If one server of order service isn’t able to manage the load, we can add another server resolving at 127.0.0.1:8090 and make use of the load balancing feature of HAProxy:
frontend haproxy_as_api_gateway
bind 127.0.0.1:80
acl PATH_order path_beg -i /order
acl PATH_invoicing path_beg -i /invoicing
use_backend order_service if PATH_order
use_backend invoicing_service if PATH_invoicing
backend order_service
server server1 127.0.0.1:8080
server server2 127.0.0.1:8090
backend invoicing_service
server server1 127.0.0.1:8081
In this way, not only are we routing the order service to a different location, but also load balancing it.
3.3. Segregating Requests by Domain
For simple scenarios, the above configurations work fine. However, in the real world, we experience complex scenarios. One such scenario is to segregate the API paths for different domains.
Let’s continue with the online store example. The order API is used by the consumer, while the invoicing is used by the operations team. We’ve two different domains for the consumer website and the operations team portal. Each domain will have its respective API paths.
If the consumer tries to access invoicing from the website, such a request shouldn’t be resolved. Similarly, requests for orders from the operations team portal shouldn’t be resolved.
Here’s how we can achieve the above scenario:
frontend haproxy_as_api_gateway
bind :80
acl consumerapi_host req.hdr(Host) -i -m dom 127.0.0.1
acl operationapi_host req.hdr(Host) -i -m dom 127.0.0.2
acl PATH_order path_beg -i /order
acl PATH_invoicing path_beg -i /invoicing
use_backend order_service if consumerapi_host PATH_order
use_backend invoicing_service if operationapi_host PATH_invoicing
backend order_service
server server1 127.0.0.1:8080
server server2 127.0.0.1:8090
backend invoicing_service
server server1 127.0.0.1:8081
With this configuration, we’ve defined two variables, consumerapi_host, and operationapi_host, for the two domains 127.0.0.1 and 127.0.0.2, respectively.
HAProxy will route the request to the order_service backend only when the request comes from consumerapi_host with the path order, i.e., 127.0.0.1:80/order. Similarly, it’ll route the request to the invoicing_service backend only when the request comes from operationapi_host with the path invoicing, i.e., 127.0.0.2:80/invoicing.
We may have a scenario where we’ve to segregate the order service based on the content type of the request. For example, a certain client may send data in XML format while another in JSON.
Here’s how we can accommodate the above requirement:
frontend haproxy_as_api_gateway
bind :80
acl consumerapi_host req.hdr(Host) -i -m dom 127.0.0.1
acl operationapi_host req.hdr(Host) -i -m dom 127.0.0.2
acl api_json req.hdr(Content-Type) -i -m dom application/json
acl api_xml req.hdr(Content-Type) -i -m dom application/xml
acl PATH_order path_beg -i /order
acl PATH_invoicing path_beg -i /invoicing
use_backend order_service_json if consumerapi_host api_json PATH_order
use_backend order_service_xml if consumerapi_host api_xml PATH_order
use_backend invoicing_service if operationapi_host PATH_invoicing
backend order_service_json
server server1 127.0.0.1:8080
backend order_service_xml
server server2 127.0.0.1:8090
backend invoicing_service
server server1 127.0.0.1:8081
We’ve now defined two different backends for the order service. 127.0.0.1:8080 will take care of all JSON requests. 127.0.0.1:8090 will take care of all XML requests.
Using the request headers, we’ve defined two variables, api_json, and api_xml, for every incoming request. We’ve added their usage only if the request comes from the consumer domain with an order in the path.
4. Rate Limiting
Rate limiting limits the number of requests from the client. In our case, we may like to rate limit the number of orders. For example, we put a limit of 100 orders in 10 seconds. Beyond that, we may expect that some malicious activity is going on. Or we may have to add extra servers to manage the load.
To begin with, we’re going to create a file path_param_rates.map. We’ll be adding the paths with their respective limits:
/order 100
In HAProxy, stick tables are used to track and save different parameters. Stick tables are fast, in-memory storage within HAProxy. They store the client session-related data in key/value pairs.
In this case, we’ll be tracking the number of times order request has been placed:
frontend haproxy_as_api_gateway
bind :80
stick-table type string size 1m expire 10s store http_rate_limiting
http-request track-sc0 base32+src
http-request set-var(req.rate_limit) path,map_beg(path_param_rates.map,20)
http-request set-var(req.request_rate) base32+src,table_http_rate_limiting()
acl rate_abuse var(req.rate_limit),sub(req.request_rate) lt 0
http-request deny deny_status 429 if rate_abuse
acl consumerapi_host req.hdr(Host) -i -m dom 127.0.0.1
acl operationapi_host req.hdr(Host) -i -m dom 127.0.0.2
acl consumerapi_json req.hdr(Content-Type) -i -m dom application/json
acl consumerapi_xml req.hdr(Content-Type) -i -m dom application/xml
acl PATH_order path_beg -i /order
acl PATH_invoicing path_beg -i /invoicing
use_backend order_service_json if consumerapi_host consumerapi_json PATH_order
use_backend order_service_xml if consumerapi_host consumerapi_xml PATH_order
use_backend invoicing_service if operationapi_host PATH_invoicing
backend order_service_json
server server1 127.0.0.1:8080
backend order_service_xml
server server2 127.0.0.1:8090
backend invoicing_service
server server1 127.0.0.1:8081
We’ve created a stick table http_rate_limiting. It clears the data after every 10 seconds.
With this configuration, if order requests exceed 100 within 10 seconds, the client receives an error with the code 429.
5. Conclusion
In this article, we’ve used HAProxy as an API Gateway. We’ve looked into the cases of HTTP Routing and Rate Limiting. HAProxy is pretty easy to configure in these use cases.
