What Is an API Proxy?

A proxy is something that acts on behalf of something else. Sitting between your application and your backend, API proxies provide an interface to developers for accessing backend services.

An API proxy is a thin API server that exposes a stable interface for an existing service or services. You can create a custom API interface for an application (often a frontend) that interacts with different parts of your backend. This allows you to define an API which adapts to the needs of your application, without having to change the underlying services in your backend.

By the end of this Hey Node introductory tutorial, you should be able to:

• Understand what an API proxy is.
• Explain the benefits of using an API proxy.

Goal

Understand what an API proxy is and how it can help you customize the way an application consumes your backend services by decoupling the frontend from implementation details of the backend. Also, learn reasons to use an API proxy including the ability to perform data transformations, hide complex calls to multiple services, and cache large or slow results.

Prerequisites

• None

Watch: What Is an API Proxy?

Definitions

First, let's define some terms we'll be using:

• API: Application Programming Interface, an interface that allows different programs to interact with each other.
• Backend services (or just "backend", or "services"): The servers, APIs, or databases that make up the parts of the architecture that your applications rely on.
• Consumers: The applications that interact with your backend. Used interchangeably with "frontends" in this article. Consumers can include mobile, web, or desktop applications as well as anyone or anything making API calls to your services.
• Shim: A shim is a layer of code which helps provide compatibility between different interfaces or APIs.

What's an API proxy?

An API proxy acts as an intermediary between a consumer and backend services. It can be a small shim, or a larger piece of code that handles data transformations, security, routing, traffic shaping and more. It can expose an interface customized for the consumer, and then makes the appropriate calls to the backend service(s) on behalf of the consumer.

Imagine you have a modern web application that needs to get information from a legacy backend that communicates in XML. Instead of making your web application talk directly to that legacy backend using XML, you can create an API proxy which the web application communicates with in JSON format. The API proxy will then translate the request from the web application into the XML format that the legacy backend is expecting, and translate the response from the backend into the JSON format the web app is expecting.

This is just one example of what an API proxy can do. In a similar scenario, the web application might need to get data across 10 different services in your backend. Instead of having the web application make all 10 of those API calls directly to the backend, you can use an API proxy to which the web application makes a single API call. The API proxy can then make all 10 calls on behalf of the web application, gather their results, and send the data back to the web application.

An API proxy exists as an intermediary, helping a consumer get the data it needs without having to talk directly to the services that provide that data.

This can be useful in situations where you want to avoid rewriting your backend services to accommodate a different access pattern, or you want to keep a consumer of these services decoupled from the implementation of the actual service. An API proxy acts as a level of abstraction between the consumer and the backend.

This pattern also allows you to expose a stable interface to the consuming application. If your backend services change, you can make the appropriate changes at the API proxy level without having to change how the consuming application accesses the data. That might sound like duplicating work, and sometimes it is, but it also allows you to insulate the developers working on the frontend from changes that might be happening on the backend. When changes occur on the backend, someone just needs to fix the API proxy implementation, and the frontend won't need to change anything at all.

Adding a layer between your frontend and backend will increase latency to some degree. An API proxy can also allow you to implement caching over some of your expensive API calls, which can ultimately decrease latency. An API proxy that makes requests and caches the combined result will improve performance for users over making separate requests.

Recap

An API proxy is an interface that sits between your frontend and the actual backend services. Using an API proxy decouples the frontend from implementation details of the backend, and allows you to create a custom interface that the frontend will interact with instead of the backend itself. Some reasons to use an API proxy include the ability to perform data transformations, hide complex calls to multiple services, and cache large or slow results.

Further your understanding

• Without an API proxy, how could changes to a backend affect its consumers? How would backend changes affect a consumer interfacing with an API proxy? In each case, what adjustments in implementation would be required?
• What other types of consumers can you think of besides a web application?
• Can you think of an example of an API proxy?

Additional resources

• IBM Node.js Backend for Frontend example (github.com)
• Backends for Frontends Pattern (samnewman.io)