Skip to main content

API Gateway

In the past, we had a large system that provided everything that was needed, better known as a Monolith. All requests were sent to it. Nowadays things have changed a lot and we've divided this into smaller systems called microservices to make it easier to develop, test, scale, divide responsibilities and manage permissions, improve security, etc.

Each microservice has its own API and depending on which endpoint of this API is used, a response will be given.

Overview of APIs​

APIs (Application Programming Interfaces) are interfaces that allow communication between systems, services, or applications. There are several types of APIs, each with specific characteristics that make them suitable for different scenarios. Let's detail the main types:

  • REST (Representational State Transfer)

    • It's the most widely used standard today. It's based on resources represented as URLs, with operations performed by HTTP methods (GET, POST, PUT, DELETE).
    • HTTP protocol.
    • Uses JSON or XML (mainly JSON currently) as data format.
    • Simpler and more widely used.
    • Easily integrable with browsers and frontends.
    • Lower performance compared to other protocols.
    • Doesn't maintain a persistent connection.
    • Generally used in public APIs, web integrations, mobile applications.
    • Uses a standard for writing called OpenAPI (formerly Swagger). Definitions can be written in JSON or YAML

  • gRPC (Google Remote Procedure Call)

    • Protocol developed by Google that uses HTTP/2 for communication, with a focus on performance. Adopts an architecture based on remote method calls.
    • HTTP/2 protocol.
    • Several formats can be used. Avro, Protobuf, MessagePack (JSON in binary format to improve performance). There are others, but they are less used.
    • High performance (lower latency).
    • Support for bidirectional streaming.
    • Strongly typed contract definition. For example, a JSON doesn't define whether true should be read as a string or boolean.
    • Greater complexity compared to REST.
    • Not friendly for direct browser navigation.
    • More used in microservices, communication between high-performance systems.

  • GraphQL

    • Query language for APIs created by Facebook, which allows the client to specify exactly what data it needs.
    • HTTP protocol.
    • JSON is the data format used.
    • Allows custom queries, reducing data overhead.
    • Ideal for applications that consume APIs with multiple clients (like web and mobile).
    • Steeper learning curve.
    • Possibility of excessively complex queries, impacting performance.
    • More used in applications with dynamic frontends, projects with a wide variety of clients.

  • SOAP (Simple Object Access Protocol)

    • An older standard that uses XML for exchanging structured messages. You'll generally find this in legacy systems.
    • Can operate over HTTP, SMTP, TCP protocols.
    • Highly standardized and reliable.
    • Includes robust specifications for security and transactions.
    • Very verbose for using XML making it slower and heavier.
    • Less flexible than REST or GraphQL.
    • Legacy systems, bank integration, financial services.

  • WebSocket

    • Allows bidirectional real-time communication between client and server through a persistent connection.
    • WebSocket protocol.
    • Text or binary can be used in the data.
    • Ideal for real-time applications.
    • Lower latency by maintaining open connections.
    • More difficult to scale compared to REST.
    • Requires specific server support.
    • Used in Chat, games, real-time updates.

One thing that should be clear before starting is that API Gateway is not a load balancer.

alt text

API Gateway Functions​

There can be microservices using different types of APIs, and how will you know where each of your microservices is?

Will you use a load balancer to group them? Will you separate by IP? By subdomain? Will you use service discovery? How will you handle their authorization? How to standardize this?

The API Gateway comes to be the wall, the hub, for all these APIs being the front for the internal world of your system that can be divided in various ways and no one needs to know how. With it we can simplify a complex system and have control over requests.

An API Gateway is very powerful and has many functions that we can explore.

alt text

With an API Gateway we have only one endpoint and it will forward (routing function), modifying if necessary (transformation), the message to the correct API (microservice). It works as an interface over interfaces (APIs).

When I said it can modify, I mean that sometimes we want to receive a message in JSON or YAML through the API Gateway and it will change to XML to send to a legacy microservice that hasn't been updated yet. This way we can standardize things.

Those who are outside don't even know how many microservices are being used, nor know the API of these microservices, only what is exposed in the API Gateway. Eventually they think you're working with a single system.

With API Gateway we can centralize the authentication and authorization process at a single entry point, avoiding having each microservice implement individually. This way we can ensure uniformity in this authentication standard or even change it centrally avoiding having to fix this in 300 microservices.

The use of API Gateway improves security, because each language used in different microservices has specific libraries that implement authentication and authorization. Avoiding using these libraries reduces the chance of being exposed to CVEs and we delegate this problem to the cloud.

The API Gateway can be configured to verify and validate authentication tokens (like JWT) before allowing traffic to microservices. This ensures that microservices never have to directly handle credentials or sensitive tokens.

It supports various different authentication providers which simplifies authentication management when you have users from different sources. Additionally it can be used for authorization verification based on RBAC or ABAC allowing simpler and cohesive permission management.

There's much more we can talk about regarding an API Gateway, in terms of scalability, flexibility, session management, etc.

The API Gateway should be used when we work with different systems, not only microservices, and we need a single entry point. It works as a turbocharged reverse proxy and when we have all requests coming through a single place it's also easier to monitor, getting a macro view of all inbound and outbound flow (number of requests, most accessed endpoints, extra stress per endpoint, response times, etc.)

Two important points are that the API Gateway also has its cache and versioning system that can be explored to facilitate performance and development.

Some services don't even have IPs such as serverless (lambda on aws, function on azure, etc.) and we can use the API Gateway to give these functions endpoints.

Another interesting functionality is to incorporate a WAF in the API Gateway for protection against DDOS attacks being able to create rules that limit access to endpoints, for example defining a number of requests per second coming from the same IP. Generally these WAFs also help us protect against other types of attacks like SQL Injection.

We can still use the API Gateway to verify request schemas avoiding delivering a request without the necessary data to the next service improving system performance. Likewise we can do error handling and return a consistent response in case the backend doesn't respond.

We still have the option to create an endpoint that chains calls to various backends and we return a single response. It's possible to do but uncommon.

Advantages​

  • Performance
  • System and integration simplification
  • Scalability
  • Security
  • Monitoring

Disadvantages​

  • Single point of failure
  • Latency if not well worked
  • Enslavement by being stuck with offered resources and prices
  • Cost when traffic is very high
  • Maintenance Cost (Personnel) especially if hosted.
  • Configuration complexity

Available Services​

For Clouds we have the offered services:

  • Amazon API Gateway
  • Azure API Management
  • Google Cloud API Gateway
  • Apigee

Most Used Self Hosted

  • Kong (Open Source)
  • Nginx Plus (Licensed)
  • Express Gateway
  • Tyk

If we don't want to use the Cloud's API Gateway even for pricing reasons we have a great option which is Kong. It's really necessary to analyze the cost of this because often the call itself to a serverless can cost more than the function execution.