This is an automated email from the ASF dual-hosted git repository.
Yilialinn pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/apisix-website.git
The following commit(s) were added to refs/heads/master by this push:
new 5b1e75a5cb7 content: improve documentation navigation and AI gateway
guide (#2113)
5b1e75a5cb7 is described below
commit 5b1e75a5cb7b59a9a30e99db706aec90a958592f
Author: Yilia Lin <[email protected]>
AuthorDate: Fri Aug 28 15:48:54 2026 +0800
content: improve documentation navigation and AI gateway guide (#2113)
---
...ai-gateway-future-trend-of-ai-infrastructure.md | 221 +++++++++------------
website/i18n/zh/code.json | 32 ++-
website/src/pages/docs.tsx | 96 ++++++++-
3 files changed, 219 insertions(+), 130 deletions(-)
diff --git
a/blog/en/blog/2025/06/18/ai-gateway-future-trend-of-ai-infrastructure.md
b/blog/en/blog/2025/06/18/ai-gateway-future-trend-of-ai-infrastructure.md
index c1bd8816699..72f03c2a8e7 100644
--- a/blog/en/blog/2025/06/18/ai-gateway-future-trend-of-ai-infrastructure.md
+++ b/blog/en/blog/2025/06/18/ai-gateway-future-trend-of-ai-infrastructure.md
@@ -1,192 +1,169 @@
---
-title: "AI Gateways: The Future Trend of AI Infrastructure"
+title: "AI Gateway Infrastructure: Roles, Boundaries, and Trends"
authors:
- name: Yilia Lin
title: Technical Writer
url: https://github.com/Yilialinn
image_url: https://github.com/Yilialinn.png
keywords:
- - API gateway
- - AI middleware
- - API gateway vs AI gateway
- - AI governance
- - AI cost control
- - AI security
- - APISIX AI gateway
-description: "Explore AI Gateway infrastructure trends and how Apache APISIX
can help manage LLM traffic, model routing, token limits, and AI application
security."
+ - AI gateway infrastructure
+ - AI infrastructure gateway
+ - AI gateway trends
+ - AI gateway market
+ - LLM gateway
+ - Apache APISIX AI gateway
+description: "Understand where an AI gateway fits in AI infrastructure, which
controls belong at the gateway, what remains elsewhere, and how to assess
adoption trends."
tags: [Ecosystem]
image:
https://static.api7.ai/uploads/2025/03/07/Qs4WrU0I_apisix-ai-gateway.webp
---
-> Discover how AI gateways are revolutionizing enterprise AI infrastructure,
offering centralized control, security, cost management, and governance for AI
models and services.
-<!--truncate-->
-
-## AI Infrastructure Revolution
-
-The enterprise AI landscape has exploded into fragmented chaos. Marketing
teams deploy GPT-4 for content generation, developers fine-tune Llama 3 for
coding assistants, while legal departments rely on Claude 3 for contract
analysis. This siloed adoption creates three critical pain points:
-
-1. **Security Vulnerabilities**: 68% of enterprises report unauthorized AI
tool usage leading to PII leaks (Gartner 2025)
-2. **Cost Overruns**: Unmonitored token consumption causes 41% of companies to
exceed AI budgets by 200%+ (McKinsey)
-3. **Governance Failure**: 83% of compliance violations trace to inconsistent
AI policy enforcement (Deloitte Audit Report)
+> An AI gateway can provide a controlled network path to model providers, but
it is only one part of production AI infrastructure. Its useful scope is
traffic policy, provider access, usage controls, and gateway-level
telemetry—not model evaluation, agent orchestration, or compliance by itself.
-Enter **AI gateways**—the middleware revolution transforming enterprise AI
from experimental tools to production-grade infrastructure. These systems
consolidate fragmented AI interactions through a unified control layer, much
like Kubernetes did for container orchestration. An AI gateway is a specialized
middleware layer that manages and secures interactions between your
applications and AI models, such as **OpenAI**'s offerings. This technology,
akin to an **API gateway**, provides visi [...]
-
-## What Is an AI Gateway
-
-An [AI
gateway](https://apisix.apache.org/blog/2025/03/06/what-is-an-ai-gateway/) is a
middleware platform designed to manage and facilitate the integration and
deployment of artificial intelligence models and services, such as OpenAI,
Anthropic, Gemini, etc. It acts as a bridge between AI models and the
applications that use them, simplifying integration and deployment, especially
for large language models. Essentially, an AI gateway serves as a crucial
control point for managing AI ser [...]
-
-
+<!--truncate-->
-## AI Gateway vs API Gateway: Critical Differences
+Organizations often begin with direct calls from an application to one model
API. As the number of applications, teams, and providers grows, that approach
can make credentials, usage policies, and operational evidence inconsistent. An
**AI gateway infrastructure** layer can provide a shared enforcement point for
traffic that already passes through it.
-While [AI gateways and API
gateways](https://apisix.apache.org/blog/2025/03/21/ai-gateway-vs-api-gateway-differences-explained/)
share some infrastructure-level similarities, they differ significantly in
purpose, functionality, and optimization.
+That does not make the gateway the center of every AI system. A production
design still needs clear owners for application authorization, retrieval, model
evaluation, workflow state, data governance, and incident response. This
article explains the gateway's practical role, its boundaries, and the adoption
signals worth evaluating without relying on market-size forecasts.
-| Feature | AI Gateway | API Gateway |
-|---------|------------|-------------|
-| Primary Use Case | Managing, securing, and optimizing traffic to AI/LLM
services (e.g., OpenAI, Anthropic, custom models) | Routing and securing
general-purpose REST/gRPC APIs for web, mobile, and microservices |
-| Request Characteristics | Often large payloads (e.g., prompts), streaming
input/output, expensive per-call | Lightweight, transactional HTTP/gRPC
requests |
-| Cost Awareness | Tracks tokens, usage costs, and budget limits per user/app
| Generally unaware of downstream compute or pricing costs |
-| Observability Needs | Input/output tracing, latency + token logging,
hallucination detection | Standard request logs, metrics (latency, throughput,
error rate) |
-| Security Features | PII redaction, prompt inspection, AI-specific abuse
filters | OAuth, JWT, IP allowlists, rate limiting |
-| Optimization Techniques | Caching AI responses, model fallback, prompt
standardization, and dynamic routing by cost or latency | Load balancing,
circuit breaking, and service discovery |
-| Plugin Support | AI-specific (e.g., pre-/post-processing, moderation,
reranking) | General plugins (e.g., auth, logging, CORS) |
-| Streaming Support | Critical: supports real-time token streaming from LLMs |
Optional: typically used for HTTP/2 or WebSocket |
-| Governance Controls | Usage quotas, cost controls, and team-level
restrictions for AI services | API-level access controls, usage policies per
role/team |
-| Integration Targets | LLM APIs (e.g., OpenAI, Anthropic, local models like
Llama), AI agents, RAG systems | Microservices, internal APIs, public-facing
APIs |
+## Key Takeaways
-**Summary of Key Distinctions**:
+- An AI gateway is a traffic intermediary for model and AI-service calls, not
an AI application runtime.
+- High-value gateway controls include client authentication, provider
credential isolation, request limits, model routing, bounded fallback, usage
accounting, and transport-level telemetry.
+- Prompt inspection and content filtering are useful policy inputs, but they
do not prove that a response is correct, safe, or compliant.
+- Provider APIs differ in request schemas, streaming behavior, token
reporting, error semantics, and pricing. A common endpoint reduces some client
coupling but does not erase those differences.
+- The right evaluation starts from explicit failure modes and responsibility
boundaries, not from a checklist that assumes every product implements the same
behavior.
-- **Focus**: AI gateways specialize in **intelligent traffic management for AI
models**, while AI gateways focus on standard API traffic orchestration.
-- **Observability**: AI gateways require **fine-grained monitoring**,
including cost and token-level visibility.
-- **Security**: AI gateways offer **general web security**, whereas AI
gateways need **content-level protections** (e.g., for prompt injection).
-- **Optimization**: AI gateways can **route based on AI-specific metrics**
(e.g., model latency, accuracy, cost), unlike traditional AI gateways.
+## Where an AI Gateway Fits
-
+An [AI
gateway](https://apisix.apache.org/blog/2025/03/06/what-is-an-ai-gateway/) sits
on the request path between authorized clients and one or more model or
AI-service endpoints. Depending on the implementation, it can apply general API
gateway policies and AI-specific processing before forwarding a request.
-## Why AI Gateways Are Essential for Enterprises?
+The traffic path and adjacent responsibilities are:
-In a world where AI adoption is accelerating, AI gateways offer a **critical
layer of control, visibility, and governance**. They enable enterprises to
confidently integrate AI into their systems securely, scalably, and sustainably.
+1. An application or agent runtime sends an authenticated model request to the
AI gateway.
+2. The gateway applies configured traffic policy and sends a provider-specific
request to a managed or private model endpoint.
+3. The gateway emits approved metrics and protected logs.
+4. Retrieval, tools, and workflow state remain connected to the application
runtime rather than moving into the gateway.
+5. Evaluation and governance systems provide reviewed policy and evidence to
the application and gateway configuration processes; they are not inline model
proxies by default.
-**You need an AI gateway when:**
+The application or agent runtime still decides why a model is called, which
tools may be used, and how results affect business state. Retrieval systems own
document selection and authorization. Evaluation systems measure quality and
safety against defined test cases. The gateway controls only the traffic and
context it can observe.
-- You're using LLMs or AI APIs in production (e.g., OpenAI, Claude, Gemini).
-- You want **centralized governance and cost control** over AI usage.
-- You need **security and content moderation** for AI prompts/responses.
-- You must **support multiple models** with fallback or dynamic routing.
+This distinction matters because many AI risks occur outside the network hop.
A gateway cannot determine whether retrieved documents were authorized
correctly, whether an agent's plan is valid, or whether a generated answer is
factually correct unless another trusted component supplies that evidence.
-Here's a breakdown of **why AI gateways are crucial** for modern enterprises:
+## Responsibilities That Fit the Gateway
-### 1. Centralized Control for AI Services
+### 1. Client Identity and Provider Credential Isolation
-Enterprises today adopt multiple AI models (e.g., OpenAI, Hugging Face,
internal LLMs) across cloud and on-prem environments. An AI gateway provides:
+The gateway can authenticate calling applications or workloads and apply
route-level authorization before a provider request is made. It can also keep
provider credentials out of distributed clients by adding the upstream
credential at the trusted gateway boundary.
-- **Routing logic** based on cost, latency, or use case.
-- **Model versioning** to avoid breaking downstream systems.
-- **Fallback mechanisms** (e.g., if GPT-4 fails, fall back to Claude).
+This design is not a substitute for business authorization. An upstream
application still has to decide whether a user may access a particular record,
tool, or action. Public browser and mobile clients should not receive a shared
provider secret.
-
+Request headers require deliberate handling. Some AI proxy implementations
forward client headers unless they are removed or overwritten. Before sending
traffic to a third-party provider, define and test an outbound header policy so
cookies, internal identity headers, and unrelated authorization values do not
cross the provider boundary.
-### 2. Security and Compliance
+### 2. Model Routing and Bounded Fallback
-AI gateways serve as security enforcement layers:
+A gateway may select an upstream by configured provider, model, priority,
weight, health signal, or another supported rule. This can centralize endpoint
changes and reduce duplicated routing code.
-- **Rate limiting and quota management** to control the usage of costly LLM
APIs.
-- **Authentication & Authorization** for internal and external consumers.
-- **PII masking and data redaction** to ensure data privacy before reaching
LLMs.
-- **Audit logs** to support compliance (e.g., GDPR, SOC 2).
+Fallback must remain bounded. Retrying a non-idempotent tool action or
replaying a large request across providers can increase cost or produce
duplicate effects. Different providers can also return materially different
answers. Define which errors are eligible, cap attempts and time, preserve an
end-to-end deadline, and expose the selected provider and fallback reason in
telemetry.
-### 3. Observability and Monitoring
+The gateway should not choose a model based on an unverified claim of answer
quality. Quality-based routing requires an evaluation method, current evidence,
and an owner outside the request proxy.
-Visibility is critical when running generative AI workloads:
+### 3. Request, Token, and Budget Controls
-- **Logging inputs/outputs and response times** for debugging.
-- **Tracing** to understand latency bottlenecks.
-- **Monitoring token usage and cost** for budget optimization.
+General request-rate and concurrency limits protect gateway and upstream
capacity. AI-aware controls can additionally use reported prompt, completion,
or total tokens when the selected integration exposes those values.
-### 4. Performance Optimization
+Token limits are not automatically financial budgets. Provider prices can vary
by model, region, cache state, batch mode, and contract. If cost allocation
matters, keep a versioned price source, record the model and usage dimensions
needed for reconciliation, and compare gateway records with provider billing
data. Do not use a best-effort in-memory counter or log queue as the financial
system of record.
-AI gateways can significantly improve efficiency:
+### 4. Gateway-Level Observability
-- **Caching responses** to avoid redundant LLM calls.
-- **Load balancing** across multiple AI model endpoints.
-- **Streaming support** for faster UX in chat applications.
+Useful gateway signals include:
-### 5. Cost Control and Governance
+- request count, status, and latency;
+- time to first token or response for streaming requests, as exposed by the
integration;
+- selected provider and model;
+- reported prompt and completion tokens;
+- retries, fallbacks, and limit rejections; and
+- connection termination or response-size limits.
-With AI APIs costing per-token or per-call, an AI gateway enables:
+Prompt and response bodies may contain personal, confidential, or regulated
data. Payload logging should be off by default unless there is a reviewed
purpose, redaction policy, access boundary, and retention period. Sampling and
redaction also need negative tests; a log statement saying that data is
protected is not evidence that secrets cannot reach a sink.
-- **Usage policies per team or app** to prevent budget overages.
-- **Token counting and cost attribution** for internal chargebacks.
-- **Auto-throttling** or alerting based on budget thresholds.
+### 5. Narrow, Testable Content Policies
-### 6. Flexibility for Hybrid/Multi-Cloud AI
+Some gateways can reject inputs using allow/deny patterns or call an external
moderation service. These controls can block known formats or policy
categories, but they have false-positive and false-negative behavior.
-AI workloads are often hybrid (cloud + on-prem) or multi-cloud. An AI gateway:
+A regular-expression prompt guard is not a semantic prompt-injection detector.
A moderation response is not proof of factual accuracy. Treat these controls as
one layer in a larger application safety design, with explicit failure behavior
when the policy service is slow or unavailable.
-- Supports **traffic routing across environments**.
-- Helps abstract away vendor-specific endpoints.
-- Allows **easy swapping of model providers** without rewriting client code.
+## What Remains Outside the Gateway
-### 7. Plugin Ecosystem for AI Use Cases
+The following responsibilities usually belong elsewhere:
-Advanced AI gateways support plugins for:
+- **Agent planning and durable workflow state:** an agent runtime or workflow
engine owns steps, approvals, compensation, and recovery.
+- **Retrieval authorization:** the application and retrieval layer decide
which documents and vector records a principal may access.
+- **Model and prompt evaluation:** an evaluation system measures quality,
robustness, and regressions using representative tests.
+- **Human approval:** business owners define which actions require review and
how an approval is recorded.
+- **Data lifecycle governance:** source systems and governance teams own
classification, residency, deletion, and legal requirements.
+- **Provider availability and billing truth:** provider APIs and billing
exports remain authoritative for their service behavior and charges.
-- **Prompt templating and standardization**
-- **Content moderation (e.g., toxicity detection)**
-- **Custom pre- and post-processing**
+An AI gateway can enforce a reviewed decision at the traffic boundary. It
should not silently become the decision maker for controls that require
business context it does not have.
-## Trends Shaping AI Gateways
+## Apache APISIX as an Implementation Example
-Here's a comprehensive look at the **trends shaping AI gateways** in 2025 and
beyond, driven by advancements in large language models (LLMs), multi-model
architectures, enterprise governance demands, and the need for scalable, secure
AI infrastructure.
+Apache APISIX combines general gateway plugins with AI-specific plugins. The
exact schema and behavior depend on the APISIX release, so verify the
documentation for the version you run. The plugin details below were verified
against APISIX 3.18.0.
-### 1. Multi-Model Routing and Federation
+- [`ai-proxy`](https://apisix.apache.org/docs/apisix/plugins/ai-proxy/)
converts supported request formats for documented model providers and can
expose model, token, duration, and time-to-first-token fields to access logs.
+-
[`ai-proxy-multi`](https://apisix.apache.org/docs/apisix/plugins/ai-proxy-multi/)
supports multiple configured model instances with documented load-balancing
and fallback behavior. In APISIX 3.18.0, when a failed upstream is retried, the
plugin records that instance's error body in the error log. Treat those logs as
potentially sensitive and review their access, export, and retention before
enabling fallback.
+-
[`ai-rate-limiting`](https://apisix.apache.org/docs/apisix/plugins/ai-rate-limiting/)
can apply token-based limits using local or supported Redis policies. Counter
availability and any degradation setting are part of the enforcement decision.
+-
[`ai-prompt-guard`](https://apisix.apache.org/docs/apisix/plugins/ai-prompt-guard/)
applies configured allow and deny patterns to recognized prompt formats. Its
`fail_mode` controls unrecognized traffic and defaults to `skip`; its scope is
pattern matching, not general semantic safety classification.
-Modern AI apps increasingly call multiple models—OpenAI for coding, Claude for
summarization, open-source LLMs for privacy.
+General authentication, request transformation, traffic control, and logging
plugins can be composed with these features. In APISIX 3.18.0, `ai-proxy`
forwards client headers other than `Host`, `Content-Length`, and
`Accept-Encoding` unless they are removed or overwritten. Strip cookies and
unrelated authorization or internal identity headers before the provider
request. Composition still requires testing of plugin order, identity
variables, outbound headers, streaming, error paths, and [...]
-- **AI gateways are evolving to support multi-model orchestration**: routing
requests based on latency, accuracy, cost, or trust.
-- **Federated AI inference** across local, edge, and cloud-hosted models is
becoming common.
+## AI Gateway Trends Worth Evaluating
-### 2. Token-Aware Cost Governance
+The phrase **AI gateway market** covers products with different scopes, from
managed model proxies to self-hosted gateway plugins and broader AI governance
platforms. Instead of treating them as interchangeable, evaluate the following
technical trends.
-Cost-first LLMOps with budget capping and per-call spend limits. LLM APIs are
priced by token, making cost tracking critical.
+### Multi-Provider Access with Explicit Semantics
-- **AI gateways now include token accounting, quota enforcement, and cost
attribution per user/team.**
-- Enterprises want **real-time dashboards** and budget guardrails to avoid
unexpected bills.
+Teams want a stable client-facing interface while retaining more than one
provider option. The practical trend is not complete provider
interchangeability. It is controlled adaptation with documented differences in
models, token fields, streaming frames, tool calls, errors, and safety settings.
-### 3. Prompt and Output Moderation Pipelines
+### Usage-Aware Traffic Policy
-**Built-in security layers** are becoming standard for enterprise-grade LLM
access. Prompt injection, jailbreaks, and hallucinations are real risks.
+Request counts alone do not describe AI workload consumption. Token usage,
response duration, concurrency, and response size are becoming important policy
dimensions. Implementations still need a defined source for usage data and a
failure policy when a provider omits or changes that data.
-- AI gateways increasingly support **pre-processing filters (for prompt
safety) and post-processing checks (for toxic/hallucinated content).**
-- Expect **pluggable moderation**, e.g., connecting to third-party content
filters or in-house classifiers.
+### Streaming as a First-Class Failure Mode
-
+Long-lived streaming responses change timeouts, capacity planning, disconnect
handling, and observability. A successful HTTP status does not prove that a
complete response reached the client. Track termination and protocol
completion, and cap resources according to the use case.
-### 4. LLMOps Integration
+### Separation of Deterministic Enforcement and Model Advice
-Gateways now help **manage deployment lifecycle, usage policies, and routing
across model updates**. AI gateways are becoming **key components of the LLMOps
stack**, sitting between orchestrators, vector stores, and foundation models.
+Model-assisted policy suggestions may help operators analyze traffic or
propose configuration. Production enforcement should remain deterministic,
authorized, reviewed, and reversible. A model recommendation should not receive
unrestricted gateway credentials or bypass the configuration delivery process.
-- Seamless integration with **vector databases, RAG pipelines, fine-tuning
services, and agent frameworks**.
-- **Unified config and telemetry** across dev/test/prod environments.
+### Clearer Boundaries with Agents, MCP, and Tools
-### 5. Hybrid and Multi-Cloud AI Infrastructure
+Agent and tool protocols add identity, session, authorization, and audit
questions. A gateway can authenticate traffic and constrain reachable
endpoints, but tool discovery, approval, workflow state, and business-side
effects remain application or runtime concerns. Products should be evaluated on
these boundaries rather than on a generic claim that one gateway "manages
agents."
-A gateway becomes the **unifying control plane** in a fragmented AI ecosystem.
AI workloads are distributed across **SaaS APIs, private clusters, edge
devices, and cloud VMs**.
+### Customer-Owned Extensions Without Forking the Gateway
-- AI gateways act as **cross-environment brokers**, abstracting model
locations and offering **location-aware routing**.
-- They ensure **policy compliance and telemetry collection** across all
inference points.
+Organizations often need customer-specific authentication, policy,
transformation, or telemetry. Prefer a supported extension surface over editing
the gateway's core. A stable plugin interface, an [external Plugin
Runner](https://apisix.apache.org/docs/apisix/external-plugin/), or an external
policy service can keep customer-owned logic separate from the base product and
reduce the merge conflicts that otherwise recur during upgrades.
-### 6. Open Standards and Ecosystem Interoperability
+This separation does not make an extension maintenance-free. Confirm that the
extension point exposes the required request or response phase, limit its
privileges and data access, define timeout and failure behavior, cap its
resource use, and test compatibility, security, and performance whenever the
gateway, plugin API, or runner changes. If the supported interface cannot
enforce a requirement safely, treat that as an architecture constraint rather
than silently patching the core.
-The ecosystem is trending toward **vendor-agnostic, modular AI
infrastructure**. Avoiding lock-in is a top concern.
+## Evaluation Checklist
-- Movement toward **standardized APIs (e.g., OpenLLM, OpenAI-compatible
APIs)**.
-- Gateways support **pluggable backends**, open telemetry, and policy engines.
+Before selecting or expanding an AI gateway, verify:
-## Conclusion: The Strategic Imperative
+1. **Traffic ownership:** Which model and tool calls actually pass through the
gateway?
+2. **Identity:** Which principal is authenticated, and where is object-level
authorization enforced?
+3. **Credential boundary:** Can client credentials or internal headers reach a
provider unintentionally?
+4. **Provider behavior:** Which request, streaming, error, and usage fields
are supported for each provider?
+5. **Failure policy:** Which failures can retry or fall back, and what
deadline and attempt limits apply?
+6. **Usage controls:** Are counters local or shared, and what happens when
their backend is unavailable?
+7. **Sensitive data:** Are prompts or responses logged, cached, exported, or
retained?
+8. **Evidence:** How are routing, limits, model quality, and policy changes
tested before rollout?
+9. **Recovery:** Can operators identify the active configuration and return to
a known-good version?
+10. **Extensibility:** Can customer policy use a supported plugin, Plugin
Runner, or external service instead of a gateway fork, and how is that
extension retested during upgrades?
+11. **Scope:** Which requirements still need an application, workflow engine,
retrieval layer, or governance system?
-AI gateways are **security enforcers, policy engines, observability hubs, and
optimization layers** for enterprise AI. As AI adoption deepens, the gateway
becomes the enterprise's trust boundary for AI. Enterprises implementing them
now gain: **risk reduction, cost control, and velocity acceleration**.
+## Conclusion
-As Anthropic CEO Dario Amodei notes: *"The next AI competitive advantage won't
come from larger models, but from smarter orchestration*."* Organizations
delaying adoption face irreversible technical debt, while early adopters
already attribute revenue growth to AI gateway-optimized personalization
systems.
+An AI gateway can make model traffic easier to govern when it is placed at a
real trust boundary and given a limited, testable set of responsibilities. Its
strongest use cases are provider credential isolation, traffic policy, bounded
routing, usage controls, and gateway-level evidence.
-The future is clear: AI gateways are becoming the **central nervous system**
of intelligent enterprises. Those who architect this layer today will dominate
the AI-driven economy of tomorrow.
+It is not a complete AI platform, a durable agent runtime, or a compliance
guarantee. Organizations evaluating AI gateway infrastructure should compare
current, documented behavior against their own traffic, data, and failure
requirements—and keep the rest of the AI system's responsibilities explicit.
diff --git a/website/i18n/zh/code.json b/website/i18n/zh/code.json
index 8bd000d1184..84b706070f7 100644
--- a/website/i18n/zh/code.json
+++ b/website/i18n/zh/code.json
@@ -12,8 +12,36 @@
"description": "Document"
},
"docs.webpage.title.DocumentSubtitle": {
- "message": "让产品与技术背后的细节更加可视化",
- "description": "We love open source."
+ "message": "根据任务选择对应的 Apache APISIX 文档集。每张卡片均会打开该项目的最新发布版文档。",
+ "description": "Choose the Apache APISIX documentation set that matches
your task. Each card opens the latest published documentation for that project."
+ },
+ "docs.meta.description": {
+ "message": "浏览 Apache APISIX 文档，涵盖 API 网关、AI 网关、Ingress Controller、Helm
Chart 和插件开发。通过指南、教程与 API 参考快速上手。",
+ "description": "Browse Apache APISIX documentation for API Gateway, AI
Gateway, Ingress Controller, Helm Chart, and plugin development. Get started
with guides, tutorials, and API references."
+ },
+ "docs.meta.ogDescription": {
+ "message": "浏览 Apache APISIX 的 API 网关、AI 网关、Ingress Controller、Helm Chart
和插件开发文档。",
+ "description": "Browse Apache APISIX documentation for API Gateway, AI
Gateway, Ingress Controller, Helm Chart, and plugin development."
+ },
+ "docs.taskNavigation.label": {
+ "message": "按任务选择文档",
+ "description": "Choose documentation by task"
+ },
+ "docs.taskNavigation.gateway": {
+ "message": "开始使用或运维 APISIX",
+ "description": "Start or operate APISIX"
+ },
+ "docs.taskNavigation.kubernetes": {
+ "message": "在 Kubernetes 上运行 APISIX",
+ "description": "Run APISIX on Kubernetes"
+ },
+ "docs.taskNavigation.plugins": {
+ "message": "选择外部插件运行器",
+ "description": "Choose an external plugin runner"
+ },
+ "docs.webpage.versionNote": {
+ "message": "需要其他版本？打开文档集并使用版本选择器。复制配置或命令前，请先确认所选版本。",
+ "description": "Need a different release? Open a documentation set and use
its version selector. Verify the selected version before copying configuration
or commands."
},
"download.website.title": {
"message": "立即下载",
diff --git a/website/src/pages/docs.tsx b/website/src/pages/docs.tsx
index db08cd83ea9..92e724841ba 100644
--- a/website/src/pages/docs.tsx
+++ b/website/src/pages/docs.tsx
@@ -31,7 +31,40 @@ const PageTitle = styled.h1`
`;
const PageSubtitle = styled.div`
- margin-bottom: 4rem;
+ max-width: 780px;
+ margin-bottom: 1.5rem;
+ font-size: 1.1rem;
+ line-height: 1.7;
+`;
+
+const TaskNav = styled.nav`
+ display: flex;
+ flex-wrap: wrap;
+ gap: 0.75rem;
+ margin-bottom: 1.5rem;
+`;
+
+const TaskLink = styled.a`
+ padding: 0.65rem 0.9rem;
+ border: 1px solid var(--ifm-color-emphasis-300);
+ border-radius: 999px;
+ font-weight: 600;
+
+ &:hover {
+ text-decoration: none;
+ border-color: var(--ifm-color-primary);
+ }
+
+ &:focus-visible {
+ outline: 3px solid var(--ifm-color-primary);
+ outline-offset: 3px;
+ border-color: var(--ifm-color-primary);
+ }
+`;
+
+const VersionNote = styled.p`
+ margin-bottom: 2.5rem;
+ color: var(--ifm-color-emphasis-700);
`;
const CardsContainer = styled.div`
@@ -129,6 +162,7 @@ interface DocInfo {
name: string;
nameInParamCase: string;
description: string;
+ githubRepo: string;
shape: string;
color: string;
version: string;
@@ -136,7 +170,34 @@ interface DocInfo {
firstDocPath: string;
}
-interface ProjectCardProps extends DocInfo { }
+type ProjectCardProps = Omit<DocInfo, 'githubRepo'>;
+
+const taskNavigation = [
+ {
+ githubRepo: 'apache/apisix',
+ label: (
+ <Translate id="docs.taskNavigation.gateway">
+ Start or operate APISIX
+ </Translate>
+ ),
+ },
+ {
+ githubRepo: 'apache/apisix-ingress-controller',
+ label: (
+ <Translate id="docs.taskNavigation.kubernetes">
+ Run APISIX on Kubernetes
+ </Translate>
+ ),
+ },
+ {
+ githubRepo: 'apache/apisix-java-plugin-runner',
+ label: (
+ <Translate id="docs.taskNavigation.plugins">
+ Choose an external plugin runner
+ </Translate>
+ ),
+ },
+];
const ProjectCard: FC<ProjectCardProps> = (props) => {
const {
@@ -151,7 +212,7 @@ const ProjectCard: FC<ProjectCardProps> = (props) => {
} = props;
return (
- <Card href={`/docs/${nameInParamCase}${firstDocPath}`}>
+ <Card id={nameInParamCase}
href={`/docs/${nameInParamCase}${firstDocPath}`}>
<Title>
<ShapeBeforeTitle
color={color}>{shapeComponentMap[shape]}</ShapeBeforeTitle>
{name}
@@ -160,7 +221,7 @@ const ProjectCard: FC<ProjectCardProps> = (props) => {
<VersionInfo className="docs-versioninfo">
Latest version
<span>{version}</span>
- released at
+ released on
<span>{releaseDate}</span>
</VersionInfo>
</Card>
@@ -177,7 +238,7 @@ const Docs: FC = () => {
const projects = docs.map((project) => <ProjectCard key={project.name}
{...project} />);
return (
- <Layout title={translate({ message: 'Documentation' })}>
+ <Layout title={translate({ id: 'docs.webpage.title.Document', message:
'Documentation' })}>
<Head>
<meta name="description" content={translate({ id:
'docs.meta.description', message: 'Browse Apache APISIX documentation for API
Gateway, AI Gateway, Ingress Controller, Helm Chart, and plugin development.
Get started with guides, tutorials, and API references.' })} />
<meta property="og:description" content={translate({ id:
'docs.meta.ogDescription', message: 'Browse Apache APISIX documentation for API
Gateway, AI Gateway, Ingress Controller, Helm Chart, and plugin development.'
})} />
@@ -187,8 +248,31 @@ const Docs: FC = () => {
<Translate id="docs.webpage.title.Document">Documentation</Translate>
</PageTitle>
<PageSubtitle>
- <Translate id="docs.webpage.title.DocumentSubtitle">We love open
source.</Translate>
+ <Translate id="docs.webpage.title.DocumentSubtitle">
+ Choose the Apache APISIX documentation set that matches your task.
Each card opens the
+ latest published documentation for that project.
+ </Translate>
</PageSubtitle>
+ <TaskNav aria-label={translate({ id: 'docs.taskNavigation.label',
message: 'Choose documentation by task' })}>
+ {taskNavigation.map((task) => {
+ const project = docs.find(({ githubRepo }) => githubRepo ===
task.githubRepo);
+ if (!project) {
+ return null;
+ }
+
+ return (
+ <TaskLink key={task.githubRepo}
href={`#${project.nameInParamCase}`}>
+ {task.label}
+ </TaskLink>
+ );
+ })}
+ </TaskNav>
+ <VersionNote>
+ <Translate id="docs.webpage.versionNote">
+ Need a different release? Open a documentation set and use its
version selector. Verify
+ the selected version before copying configuration or commands.
+ </Translate>
+ </VersionNote>
<CardsContainer>{projects}</CardsContainer>
</Page>
</Layout>
