Skip to main content
Skip table of contents

Overview of API Gateway, its capabilities and plugins

This guide provides an overview of Apache APISIX, its core capabilities, and common plugins. Understanding APISIX will be crucial as it now plays a key role in our API infrastructure.

Our Current API Traffic Flow:

CODE 
Internet
   |
   v
rke2-ingress-nginx  (Kubernetes Ingress Controller)
   |
   v  (Single main ingress route directs traffic to APISIX)
APISIX Data Plane   (Our API Gateway)
   |
   v
Your Backend Services

In this setup, rke2-ingress-nginx handles the initial entry into our Kubernetes cluster, and then forwards relevant API traffic to APISIX. APISIX then acts as the central control point for managing, securing, and routing this traffic to our various backend services.

What is Apache APISIX?

Apache APISIX is a dynamic, real-time, high-performance API gateway. It's designed for cloud-native environments and offers powerful features to handle our API traffic efficiently and securely.

How APISIX Works: A Brief Overview

When a request arrives at APISIX, it goes through a series of phases. Here's a simplified view of the process:

  1. Request Ingestion: APISIX (built on Nginx) receives the incoming HTTP/S, gRPC, WebSocket, etc., request.

  2. Configuration Loading: APISIX dynamically loads its routing rules and plugin configurations from its configuration center (typically etcd). This is why changes are "hot-reloaded" without restarts.

  3. Route Matching: APISIX evaluates the incoming request (based on its host, path, headers, method, etc.) against the defined routes to find a match. Routes have priorities, so the highest priority matching route is chosen.

  4. Plugin Execution (Lifecycle Phases): Once a route is matched, the plugins associated with that route (and any globally configured plugins) are executed in a specific order through various phases of the request lifecycle. Key phases include:

    • rewrite phase: Plugins in this phase can modify the request before further processing (e.g., proxy-rewrite to change the URI, or authentication plugins that might add user information to headers).

    • access phase: Plugins here typically handle authentication, authorization, and rate-limiting (e.g., jwt-auth, key-auth, limit-req). If a plugin in this phase denies the request, the process stops, and an error is returned.

    • before_proxy phase (for some plugins): Allows modifications just before the request is sent to the upstream service.

    • (Proxying to Upstream): If the request is allowed, APISIX forwards it to the configured upstream (backend) service, performing load balancing if multiple upstream nodes are defined.

    • header_filter phase: After receiving the response headers from the upstream, plugins in this phase can modify them.

    • body_filter phase: After receiving the response body from the upstream, plugins in this phase can modify it (e.g., response-rewrite).

    • log phase: Plugins in this phase execute after the response has been sent to the client. This is where logging plugins (http-logger, kafka-logger, prometheus) typically operate.

  5. Response to Client: APISIX sends the final (potentially modified) response back to the original client.

Simplified Text Diagram of Request Flow & Plugin Execution:

image-20250529-070403.png

CODE 
Client Request --> [APISIX Data Plane]
                     |
                     V
              1. Route Matching
                  (Finds the correct route based on request attributes)
                     |
                     V
              2. Plugin Execution (Phases):
                  |
                  |--> Rewrite Phase (e.g., modify request URI, headers)
                  |     (Plugins: proxy-rewrite, some auth plugins)
                  |
                  |--> Access Phase (e.g., authentication, rate limiting)
                  |     (Plugins: jwt-auth, key-auth, limit-req, ip-restriction)
                  |     (If denied, send error to client)
                  |
                  |--> (Potentially other phases like before_proxy)
                  |
                  V
              3. Proxy to Upstream Service
                  (Load balancing, health checks)
                  |
                  V
              4. Upstream Service Processes Request
                  |
                  V
              5. Response from Upstream --> [APISIX Data Plane]
                                             |
                                             V
                                      6. Plugin Execution (Response Phases):
                                          |
                                          |--> Header Filter Phase (e.g., modify response headers)
                                          |
                                          |--> Body Filter Phase (e.g., modify response body)
                                          |     (Plugins: response-rewrite)
                                          |
                                          V
                                      7. Log Phase (e.g., send logs, metrics)
                                          (Plugins: http-logger, prometheus)
                                             |
                                             V
Client Response <----------------------- [APISIX Data Plane]

Core Abilities of Apache APISIX: What Can It Do For Us?

APISIX brings a wealth of functionalities that will enhance our API management:

  1. Dynamic Configuration & Hot Reloading:

    • What it means: Changes to routes, plugins, or configurations are applied instantly without requiring a restart of APISIX.

    • Benefit: Zero downtime for configuration updates, leading to higher availability and faster iteration.

  2. High Performance & Scalability:

    • What it means: Built on top of Nginx and using etcd for distributed configuration management, APISIX is designed for low latency and high throughput. It can handle a large volume of API calls.

    • Benefit: Ensures our APIs remain responsive and can scale with growing demand.

  3. Flexible & Powerful Routing:

    • What it means: APISIX can route requests based on a wide range of attributes, including:

      • Request domain (e.g., api.example.com)

      • Path (e.g., /users, /products)

      • HTTP methods (GET, POST, PUT, etc.)

      • Request headers (e.g., Content-Type, Authorization)

      • Query parameters (e.g., ?version=2)

      • Client IP address

      • Custom logic using expressions.

    • Benefit: Fine-grained control over how API requests reach specific backend services or versions. Enables practices like canary releases and A/B testing.

  4. Comprehensive Security Features:

    • What it means: APISIX provides multiple layers of security for our APIs (many implemented via plugins, see below).

    • Benefit: Protects our services from unauthorized access, attacks, and misuse.

  5. Rich Traffic Management Capabilities:

    • What it means: Control and shape the flow of traffic.

      • Load Balancing: Distributes traffic across multiple instances of our backend services (e.g., round-robin, consistent hashing).

      • Health Checks: Monitors the health of backend services and automatically routes traffic away from unhealthy instances.

      • Circuit Breaking: Prevents cascading failures by temporarily stopping requests to services that are failing.

      • Rate Limiting & Quota: Protects APIs from overload and abuse by limiting the number of requests a client can make.

      • Request/Response Transformation: Modify requests before they hit our services (e.g., rewrite paths, add headers) or modify responses before they reach the client.

    • Benefit: Improves API reliability, resilience, and protects backend resources.

  6. Extensibility through Plugins:

    • What it means: APISIX's functionality can be easily extended using a wide array of pre-built plugins or by developing custom plugins (in Lua, Go, Python, Java, or Wasm).

    • Benefit: Allows us to tailor APISIX to our specific needs and integrate with existing systems.

  7. Multi-Protocol Support:

    • What it means: Beyond standard HTTP/1.1 and HTTP/2, APISIX also supports:

      • gRPC proxying

      • WebSocket proxying

      • TCP/UDP proxying

      • MQTT proxying (for IoT)

      • HTTP/3 (QUIC)

    • Benefit: Future-proofs our gateway as we adopt different communication protocols.

  8. Observability & Monitoring:

    • What it means: APISIX integrates with popular monitoring and logging tools.

      • Logging: Detailed access logs can be sent to various systems (e.g., Kafka, Elasticsearch, Splunk).

      • Metrics: Exposes extensive metrics compatible with Prometheus for monitoring and alerting.

      • Distributed Tracing: Integrates with systems like Zipkin, OpenTelemetry, and SkyWalking to trace requests across services.

    • Benefit: Provides visibility into API performance, errors, and usage patterns, aiding in troubleshooting and optimization.

  9. Cloud-Native & Platform Agnostic:

    • What it means: Works seamlessly in containerized environments like Kubernetes. It can run on bare metal, VMs, or any cloud. Integrates with service discovery mechanisms like etcd, Consul, Nacos.

    • Benefit: Fits well within our existing and future infrastructure.

  10. Developer-Friendly:

    • What it means: Offers a RESTful Admin API for programmatic configuration and a user-friendly Dashboard for visual management.

    • Benefit: Simplifies API management tasks for developers and operations teams.

Major and Common APISIX Plugins: A Quick Look

Plugins are the heart of APISIX's extensibility. Here are some common ones we're likely to use or encounter:

🛡️ Security Plugins

  • key-auth:

    • Definition: Authenticates requests using API keys. Clients must provide a valid key in their request (usually in a header).

    • Use Case: Basic API protection, client identification, and usage tracking.

  • jwt-auth:

    • Definition: Validates JSON Web Tokens (JWTs) sent by clients. Ensures the token is properly signed, not expired, and optionally, checks claims.

    • Use Case: Secure, stateless authentication for microservices and web/mobile applications.

  • basic-auth:

    • Definition: Implements standard HTTP Basic Authentication (username/password).

    • Use Case: Simple authentication for internal or less sensitive APIs.

  • openid-connect (OIDC):

    • Definition: Integrates with OIDC providers (like Keycloak, Okta, Auth0) for authentication and authorization, acting as a relying party.

    • Use Case: Robust, standards-based authentication, enabling Single Sign-On (SSO).

  • ip-restriction:

    • Definition: Allows or denies requests based on the client's IP address (whitelisting or blacklisting).

    • Use Case: Restricting access to trusted IP ranges or blocking known malicious IPs.

  • cors:

    • Definition: Manages Cross-Origin Resource Sharing headers, allowing browsers to make requests to our APIs from different domains.

    • Use Case: Essential for frontend applications hosted on a different domain than the APIs.

🚦 Traffic Management Plugins

  • limit-req:

    • Definition: Limits the request rate (e.g., requests per second/minute) from a specific client (identified by IP, key, etc.).

    • Use Case: Preventing abuse and ensuring fair usage of API resources.

  • limit-count:

    • Definition: Limits the total number of requests allowed for a client within a specific time window.

    • Use Case: Enforcing quotas or usage tiers.

  • proxy-rewrite:

    • Definition: Modifies request attributes (like URI path, host, headers) before forwarding the request to the backend service.

    • Use Case: Standardizing API paths, routing to different backend versions internally, or adding contextual information.

  • response-rewrite:

    • Definition: Modifies response attributes (like status code, body, headers) from the backend before sending it to the client.

    • Use Case: Customizing error responses, removing sensitive headers, or transforming data formats.

  • traffic-split:

    • Definition: Distributes percentages of incoming traffic to different backend services or versions.

    • Use Case: Implementing canary releases (testing new versions with a small user subset) or A/B testing.

  • api-breaker (Circuit Breaker):

    • Definition: Monitors backend service health. If a service becomes unhealthy (e.g., too many errors, high latency), it "opens the circuit" and stops sending traffic to it for a period, returning a default response instead.

    • Use Case: Improving system resilience by preventing cascading failures.

👀 Observability Plugins

  • prometheus:

    • Definition: Exposes APISIX metrics (request counts, latency, status codes, etc.) in a format that Prometheus can scrape.

    • Use Case: Monitoring API performance and health, creating dashboards, and setting up alerts.

  • http-logger:

    • Definition: Sends detailed access logs to a specified HTTP endpoint.

    • Use Case: Centralizing logs in systems like Elasticsearch (via Logstash/Fluentd) or other log management platforms.

  • kafka-logger:

    • Definition: Pushes access logs to a Kafka topic.

    • Use Case: Streaming logs for real-time analysis, auditing, or feeding into big data pipelines.

  • zipkin / skywalking / opentelemetry:

    • Definition: Integrates with distributed tracing systems to provide end-to-end visibility of requests as they travel through APISIX and our backend microservices.

    • Use Case: Debugging latency issues, understanding service dependencies, and analyzing complex request flows.

🚀 Other Notable Plugins

  • proxy-cache:

    • Definition: Caches responses from backend services to reduce latency and load on upstreams for frequently accessed, static, or semi-static content.

    • Use Case: Improving performance for GET requests.

  • serverless:

    • Definition: Allows running custom Lua code directly within APISIX at various phases of the request lifecycle, without needing a separate backend service.

    • Use Case: Implementing quick request validations, light transformations, or custom authentication logic at the edge.

Why is this important for us?

Integrating APISIX provides several key benefits:

  • Centralized Control: A single point to manage security, routing, and policies for all our APIs.

  • Enhanced Security: Robust mechanisms to protect our valuable services.

  • Improved Reliability & Performance: Features like load balancing, health checks, and caching contribute to a more stable and faster API experience.

  • Faster Development Cycles: Dynamic configuration allows for quicker deployment of changes and new API features.

  • Better Observability: Deeper insights into how our APIs are being used and how they are performing.

  • Future-Readiness: Support for various protocols and a flexible plugin architecture allows us to adapt to new requirements easily.

We encourage everyone to familiarize themselves with APISIX. The official documentation (https://apisix.apache.org/docs/apisix/getting-started/ ) is an excellent resource. We will also be conducting further deep-dive sessions as needed.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close