Expand Authors Top

If you have a few years of experience in the Java ecosystem and you’d like to share that with the community, have a look at our Contribution Guidelines.

Expanded Audience – Frontegg – Security (partner)
announcement - icon User management is very complex, when implemented properly. No surprise here.

Not having to roll all of that out manually, but instead integrating a mature, fully-fledged solution - yeah, that makes a lot of sense.
That's basically what Frontegg is - User Management for your application. It's focused on making your app scalable, secure and enjoyable for your users.
From signup to authentication, it supports simple scenarios all the way to complex and custom application logic.

Have a look:

>> Elegant User Management, Tailor-made for B2B SaaS

Generic Top

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> CHECK OUT THE COURSE

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.

3.4. Segregating Requests by Data Format

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.

Generic bottom

Get started with Spring 5 and Spring Boot 2, through the Learn Spring course:

>> CHECK OUT THE COURSE
Cloud footer banner
Comments are closed on this article!