What is an API Proxy?

‍

Consuming APIs is a critical part of modern application development. APIs are the glue that connects a growing number of services to your application. Other companies are working hard to make their services available to you via APIs; if the service you need isn't available via an API, you're probably going to look somewhere else, and spend your money at a competitor!

However, when consuming APIs, you might want to set up an API proxy between your application and the APIs you're consuming. In this article, we'll go over what an API proxy is, the two main types of API proxies, why would you use one, and what is a distributed API proxy.

So don your space helmet 🧑‍🚀, and let's blast off!

API proxies: a space-themed metaphor  🚀

The purpose of an API proxy is to act as an intermediary between one or more applications and the APIs they use. It handles the request and response process,
providing a layer of abstraction and control between the applications and the APIs.

Let's take a look at a space-themed metaphor to understand the two main types of API proxies: client-side and server-side.

Imagine your application as Earth 🌍, and the server it communicates with as an alien civilization 👽. The API (Application Programming Interface) is the universal language they use to communicate. Earth is sending requests 📨 and receiving responses from the alien civilization: either a success 📝 or an error 🚫.

When getting started - during the PoC stage, or perhaps for testing purposes, your app can communicate directly with the server.

sequenceDiagram
    participant Earth as 🌍 Your application
    participant Alien as 👽 The server
    Earth->>Alien: 📨 Request
    Alien->>Earth: 📝 Successful Response

However, direct communication can sometimes be risky or inefficient. In a public API scenario (communicating with unknown alien civilizations 👽), API proxies can provide control, security, and insights. That's where API proxies, represented by the Moon 🌔 (client-side) and a Satellite 🛰️ (server-side), come into play.

Server-side API proxy 🛰️

In reality, every production server application is going to have a proxy between it and the outside world. The server can't talk to the clients directly (The aliens don't want to talk to Earth directly): they want to talk through a server-side API proxy (Satellite 🛰️). The most basic feature of a a server-side API proxy is doing Load Balancing: it sends messages from your application to multiple server instances in a round-robin fashion. It then sends the responses back to your application.

The server-side API proxy is also responsible for enforcing policies, such as authentication & authorization.

sequenceDiagram
    box Client-side
    participant Earth as 🌍 Your application
    end
    box Server-side
    participant Satellite as 🛰️ Server-side API proxy
    participant Alien1 as 👽 Server 1
    participant Alien2 as 👽 Server 2
    participant Alien3 as 👽 Server 3
    end

    Earth->>Satellite: 📨📨📨 3 Requests
    note over Satellite: For each request, check authentication,
authorization, enforce policies, etc.
    activate Satellite
    par
    Satellite->>+Alien1: 📨 Request (1)
    Satellite->>+Alien2: 📨 Request (2)
    Satellite->>+Alien3: 📨 Request (3)

    Alien1->>-Satellite: 📝 Successful Response (1)
    Alien2->>-Satellite: 📝 Successful Response (2)
    Alien3->>-Satellite: 📝 Successful Response (3)
    end
    deactivate Satellite

    Satellite->>Earth: 📝📝📝 3 Successful Responses

Usually, the API proxy is doing more than just load balancing. It can also provide features for the API provider. One of the features for the server - and usually a headache for the client - is **Rate Limiting**: in an API proxy, it's a technique for controlling the number of requests a client can send to a server in a specific time period. Read our blog post about API consumption issues to play around with a real server that does this!

In our example, the rate limit starts after 3 requests. The first three requests are successful, but the fourth request onwards is rejected with an 429 error 🚫.

sequenceDiagram
    box Client-side
    participant Earth as 🌍 Your application
    end
    box Server-side
    participant Satellite as 🛰️ Server-side API proxy
    participant Alien as 👽 Servers
    end

    Earth->>Satellite: 📨📨📨📨📨 5 Requests
    note over Satellite: Check authentication, authorization, enforce policies, etc.
One of these policies is rate-limiting.
    activate Satellite
    Satellite->>+Alien: 📨 Request (1)
    Satellite->>+Alien: 📨 Request (2)
    Satellite->>+Alien: 📨 Request (3)
    note over Satellite: Rate limiting starts after 3 requests.
Requests are not sent to the servers.
    Satellite->>Earth: 🚫 429 Too Many Requests (4)
    Satellite->>Earth: 🚫 429 Too Many Requests (5)
    Alien->>-Satellite: 📝 Successful Response (1)
    Alien->>-Satellite: 📝 Successful Response (2)
    Alien->>-Satellite: 📝 Successful Response (3)
    deactivate Satellite

    Satellite->>Earth: 🚫🚫📝📝📝 2 Errors, 3 Successful Responses

Client-side API proxy 🌔

What happens without a client-side API proxy 🌔?

Dealing with all the consumption issues is a headache for the client. Usually as an API consumer, we also want to horizontally scale our application, and we want to do it without having to deal with all the issues that come with it on each instance of your application separately, especially if the way we deal with the issues is stateful.

In this illustration, multiple instances of your app (Earths 🌍) are each sending five messages 📨 to the 👽 Servers via the 🛰️ Server-side API proxy. However, the satellite cannot handle the load...

sequenceDiagram
    box Client-side
    participant Earth1 as 🌍 Earth 1
    participant Earth2 as 🌍 Earth 2
    participant Earth3 as 🌍 Earth 3
    end
    box Server-side
    participant Satellite as 🛰️ Server-side API proxy
    participant Alien as 👽 Servers
    end

    note over Earth1,Earth3: Multiple Earths are each sending five messages to the aliens.

    Earth1->>Satellite: 📨📨📨📨📨 5 Requests
    Earth2->>Satellite: 📨📨📨📨📨 5 Requests
    Earth3->>Satellite: 📨📨📨📨📨 5 Requests

    note over Satellite: The satellite cannot handle the load.
    Satellite--)Satellite: Catastrophic failure 💥

    Satellite->>Earth1: 🚫🚫🚫🚫🚫 5 Errors
    Satellite->>Earth2: 🚫🚫🚫🚫🚫 5 Errors
    Satellite->>Earth3: 🚫🚫🚫🚫🚫 5 Errors

    note over Earth1,Earth3: The Earths receive errors, leading to dissatisfaction 🙁.

...so your application is only getting back errors 🚫, leading to dissatisfaction.

What happens with a client-side API proxy 🌔?

The Earth 🌍 needs a solution: and a distributed client-side API proxy is the answer!

This is where the Moon 🌔 comes into play: a client-side, distributed API proxy. It can handle all the consumption issues for all the instances of your application 🌍. The client-side API proxy 🌔 is also horizontally scalable: so with a distributed API proxy, state 💭 is shared between all the API proxy instances 🌔, so while being deploying multiple times, it behaves like a single proxy as far as your application instances 🌍 are concerned.

In this scenario, the client-side distributed API proxy 🌔 is sending the requests 📨 to the servers 👽, but unlike the previous scenario, the API proxy 🌔 is intelligently managing the rate limit, so that the servers 👽 are not overwhelmed.

sequenceDiagram
    box Client-side
    participant Application as 🌍 Your Application
(multiple instances)
    participant Moon as 🌔 Client-side API proxy
    participant State as 🌔💭 API proxy state
    end
    box Server-side
    participant Satellite as 🛰️ Server-side API proxy
    participant Alien as 👽 Servers
    end

    note over Application: Multiple instances are each sending
five messages to the server,
via the 🌔 Client-side API proxy.

    Application->>Moon: 📨📨📨📨📨 5 Requests (Instance 1)
    Application->>Moon: 📨📨📨📨📨 5 Requests (Instance 2)
    Application->>Moon: 📨📨📨📨📨 5 Requests (Instance 3)

    note over Moon,State: Intelligently managing the rate limit.

    loop
    Moon->>+Satellite: 📨📨📨 3 Requests
    Moon-->>+State: We sent 3 requests.
    State-->>Moon: Wait for the server
to have more capacity.
    Satellite->>+Alien: 📨📨📨 3 Requests

    Alien->>-Satellite: 📝📝📝 3 Successful Responses
    Satellite->>-Moon: 📝📝📝 3 Successful Responses
    Moon-->>State: We got 3 responses.
    State-->>-Moon: Good! Send more requests.
    end
    

    Moon->>Application: 📝📝📝📝📝 Successful Responses (Instance 1)
    Moon->>Application: 📝📝📝📝📝 Successful Responses (Instance 2)
    Moon->>Application: 📝📝📝📝📝 Successful Responses (Instance 3)

Check it out! The server is protected from being overwhelmed, and the client works optimally, without having to worry about all the consumption issues.

The server got a Translation 🔄, Efficiency ⏱️, and Security 🔒 upgrade. Your app got a Control 🎛️, Insight 🔍, and Scalability 📈 upgrade. The aliens 👽 are happy, and so are the Earths 🌍: all thanks to API proxies!

In conclusion, API proxies, like the Moon and Satellite in our cosmic metaphor, are crucial tools for efficient, secure, and controlled communication in the vast universe of application interactions. 🚀

How can Lunar help?

Assisting developers in crafting incredible applications using APIs is the core mission behind Lunar 🌑 🌒 🌓 🌔 🌕. Just like the moon serving as a reliable intermediary in the cosmic dance of Earth 🌍 and alien civilizations 👽, Lunar is designed to streamline your interactions with your business-critical APIs.

Lunar equips you with the tools to navigate these interstellar communications. It empowers your engineers to control and intercept outgoing traffic (like Earth's 🌍 messages 📨 going to the moon 🌔), build resilience (like the moon buffering and managing messages to prevent the satellite 🛰️ from exploding 💥), and enforce policies from a single unified interface.

Lunar is the more coherent alternative for overseeing and managing the third-party APIs - your alien civilizations 👽 - that your business relies on, ensuring a smooth and secure journey through the vast universe of application interactions.

Want to learn more? Check out our website or get access to check out the beta by emailing info@lunar.dev.

‍