--- title: "Why Your API Gateway Should Be TypeScript-Native" description: "TypeScript surged 66% to become GitHub's most-used language, driven by AI coding tools. Learn why a TypeScript-native API gateway gives you a real edge." canonicalUrl: "https://zuplo.com/blog/2026/03/12/typescript-number-one-language-api-gateway" pageType: "blog" date: "2026-03-12" authors: "nate" tags: "TypeScript, AI, API Gateway" image: "https://zuplo.com/og?text=TypeScript%20Is%20Now%20%231%20on%20GitHub%20%E2%80%94%20Why%20Your%20API%20Gateway%20Should%20Be%20TypeScript-Native" --- TypeScript just became the most-used programming language on GitHub. According to [GitHub's Octoverse 2025 report](https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/), TypeScript surged 66% year-over-year, overtaking both Python and JavaScript with over 2.6 million monthly contributors. The cause isn't just framework defaults or developer preference — it's AI. AI coding assistants like GitHub Copilot, Claude Code, and Cursor are fundamentally reshaping which languages developers choose. And it turns out, statically-typed languages like TypeScript give AI tools exactly the guardrails they need to produce reliable code. This has massive implications for how you should think about your API infrastructure. ## The TypeScript surge: what the data shows The numbers from Octoverse 2025 are hard to ignore. TypeScript grew by over 1 million contributors in a single year — a 66% increase that made it the #1 language on GitHub as of August 2025, displacing Python for the first time. This isn't a fluke. As [InfoQ reported](https://www.infoq.com/news/2026/03/ai-reshapes-language-choice/), the shift is being driven by a structural change in how developers write code. Nearly 80% of new GitHub developers used Copilot within their first week on the platform. Over 1.1 million public repositories now import an LLM SDK — up 178% year-over-year. TypeScript's rise isn't happening in isolation. Across the board, typed languages are growing faster than their untyped counterparts. Luau (Roblox's typed scripting language) grew 194%. Typst, a typed alternative to LaTeX, grew 108%. The pattern is clear: when AI is writing your code, types matter. ## The "convenience loop" — why static typing wins in the AI era GitHub Senior Developer Advocate Andrea Griffiths calls it a "convenience loop." When AI makes a technology feel frictionless, developers adopt it. More developers means more training data. More training data means better AI suggestions. Better suggestions mean more adoption. And the cycle continues. TypeScript sits at the center of this loop for a simple reason: **types are specifications that both humans and LLMs can read.** When you're using an AI coding assistant, TypeScript's type annotations tell the model exactly what a function expects, what a component accepts, and what a data structure looks like. Without types, the AI is guessing. With types, it's reading a spec. The data backs this up. A 2025 study cited by Visual Studio Magazine found that **94% of compilation errors in LLM-generated code were type-check failures**. TypeScript catches these automatically at compile time — before the code ever runs. This creates a feedback loop where AI-assisted TypeScript development is measurably faster and safer than working in dynamically-typed languages. For API infrastructure specifically, this matters even more. Gateway configurations, authentication logic, and request transformations are security-critical code paths. You don't want your AI assistant guessing at the shape of a request object or the return type of an auth handler. ## Why your API gateway's language matters more than ever Here's something most teams don't think about: the language your API gateway uses for configuration and extensibility directly affects how well AI tools can help you build and maintain it. Consider the major API gateways and their extensibility languages: - **Kong** primarily uses Lua — a niche language with a small community and limited AI training corpus. While Kong also supports Go and JavaScript plugins via external plugin servers, these run as separate processes with IPC overhead. Custom plugins still require familiarity with Kong's Lua-based PDK, and AI assistants have far less training data to generate correct Kong-specific code. - **Apigee** relies on XML-based policy configuration with limited JavaScript extensibility. The XML configuration is verbose, hard to validate, and notoriously difficult for AI tools to generate correctly. Custom logic runs on a legacy JavaScript engine with significant constraints. - **Tyk** uses Go for plugins — a solid language, but not the ecosystem leader for web APIs. Go's verbose error handling patterns and plugin compilation requirements add friction that AI-generated code often gets wrong. - **AWS API Gateway** uses JSON/YAML configuration with limited programmability. Custom logic requires Lambda functions in a separate service, fragmenting your gateway logic across multiple codebases. Now compare that to an API gateway where you write policies, handlers, and transformations directly in TypeScript — the language that AI tools are best at generating. ## How Zuplo's TypeScript-native model enables AI-assisted API development Zuplo is built from the ground up on TypeScript. Every policy, every custom handler, every request transformation is written in TypeScript with full type safety. This isn't TypeScript bolted onto a gateway that was designed for another language — it's the core programming model. Here's why that matters in the AI era: ### You write gateway logic in the language AI understands best When you ask an AI assistant to generate a Zuplo policy, it's working with the most popular language on GitHub. The model has seen millions of TypeScript examples. It understands the patterns, the idioms, and the type system deeply. Compare that to asking an AI to write a Kong Lua plugin or an Apigee XML policy. The training data for those niche configurations is a tiny fraction of what's available for TypeScript, and the generated code is far less likely to be correct on the first try. ### Web standard APIs mean AI models already know the primitives Zuplo's runtime is built on [Web Standard APIs](https://zuplo.com/docs/programmable-api/web-standard-apis) — the same `Request`, `Response`, `Headers`, and `fetch` APIs that every web developer (and every AI model) already knows. When an AI assistant generates code that creates a new `Response` object or reads request headers, it's using the same APIs it's seen in millions of web applications. There's no proprietary SDK to learn. No gateway-specific abstractions that the AI has never encountered. Just standard web APIs with TypeScript types. ### OpenAPI-native routing provides context for AI code generation Zuplo is [OpenAPI-native](https://zuplo.com/docs/articles/openapi) — your route configuration _is_ your OpenAPI spec. This means your API's type definitions, request schemas, and response shapes are all defined in a standard, machine-readable format that AI tools can consume directly. When you ask an AI assistant to write a validation policy for a specific endpoint, it can read the OpenAPI schema to understand exactly what fields the request body should contain, what types they should be, and what constraints apply. The result is generated code that's correct by construction. ### GitOps workflow enables AI-assisted code review Because Zuplo uses a [GitOps workflow](https://zuplo.com/docs/articles/source-control) where all configuration lives as code in your repository, AI tools can assist with more than just writing new code. They can review pull requests, suggest improvements to existing policies, and catch potential issues in configuration changes — all through the same Git-based workflow your team already uses. ## Practical examples: AI-assisted gateway development with Zuplo Let's look at what AI-assisted API gateway development actually looks like with a TypeScript-native gateway. ### Generating a dynamic rate-limiting policy Say you want rate limiting that varies by customer tier. In Zuplo, you'd write a TypeScript function that an AI assistant can generate with high confidence: ```typescript import { CustomRateLimitDetails, ZuploContext, ZuploRequest, } from "@zuplo/runtime"; export function rateLimit( request: ZuploRequest, context: ZuploContext, policyName: string, ): CustomRateLimitDetails { const user = request.user; if (user.data.customerType === "premium") { return { key: user.sub, requestsAllowed: 1000, timeWindowMinutes: 1, }; } if (user.data.customerType === "free") { return { key: user.sub, requestsAllowed: 5, timeWindowMinutes: 1, }; } return { key: user.sub, requestsAllowed: 50, timeWindowMinutes: 1, }; } ``` This code is straightforward TypeScript that any AI assistant can generate correctly. The types from `@zuplo/runtime` tell the AI exactly what `request.user` contains, what the return type should look like, and what methods are available. You wire this into a [rate limiting policy](https://zuplo.com/docs/policies/rate-limit-inbound) with a simple JSON configuration. Now imagine asking an AI to do the equivalent in Lua for Kong. It would need to understand Kong's PDK (Plugin Development Kit), Lua's table semantics, and the specific plugin lifecycle hooks — knowledge that's far less represented in AI training data. ### Writing a custom authentication handler Need a custom auth check? In Zuplo, it's a [custom inbound policy](https://zuplo.com/docs/policies/custom-code-inbound) written in TypeScript: ```typescript import { ZuploRequest, ZuploContext } from "@zuplo/runtime"; type PolicyOptions = { allowedIssuers: string[]; }; export default async function authPolicy( request: ZuploRequest, context: ZuploContext, options: PolicyOptions, policyName: string, ): Promise { const token = request.headers.get("authorization")?.replace("Bearer ", ""); if (!token) { return new Response(JSON.stringify({ error: "Missing auth token" }), { status: 401, headers: { "content-type": "application/json" }, }); } // Validate the token against your auth service const validation = await fetch("https://auth.example.com/validate", { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ token }), }); if (!validation.ok) { return new Response(JSON.stringify({ error: "Invalid token" }), { status: 401, headers: { "content-type": "application/json" }, }); } const userData = await validation.json(); if (!options.allowedIssuers.includes(userData.issuer)) { return new Response(JSON.stringify({ error: "Unauthorized issuer" }), { status: 403, headers: { "content-type": "application/json" }, }); } return request; } ``` Every line of this code uses APIs that AI models have seen millions of times: `fetch`, `Response`, `Headers`, `JSON.stringify`. The TypeScript types make the function signature self-documenting. An AI assistant can generate this entire policy from a natural-language description like "write a policy that validates bearer tokens against an external auth service and checks the issuer." ### Building a request transformation Transforming requests before they hit your backend is a common gateway task. In Zuplo, you write a [custom handler](https://zuplo.com/docs/handlers/custom-handler) in TypeScript: ```typescript import { ZuploRequest, ZuploContext } from "@zuplo/runtime"; export default async function transformHandler( request: ZuploRequest, context: ZuploContext, ) { const body = await request.json(); // Transform the request for the downstream service const transformed = { userId: request.user?.sub, payload: body, metadata: { requestId: context.requestId, timestamp: new Date().toISOString(), region: request.headers.get("cf-ipcountry") ?? "unknown", }, }; return fetch(`https://api.backend.example.com/v2/process`, { method: "POST", headers: { "content-type": "application/json", "x-request-id": context.requestId, }, body: JSON.stringify(transformed), }); } ``` Again — standard `fetch`, standard `Request` and `Response`, standard JSON handling. An AI assistant generates this naturally because it's the same code pattern used in every TypeScript web application. ## The compounding advantage The TypeScript advantage for API gateways isn't just about writing code faster today. It compounds over time: - **Onboarding is faster.** New team members already know TypeScript. They don't need to learn Lua, Go plugin patterns, or proprietary XML schemas. - **AI assistance gets better.** As more developers use TypeScript and more TypeScript code enters AI training sets, the quality of AI-generated TypeScript continues to improve — including for API gateway use cases. - **Maintenance is easier.** When you need to update a policy six months from now, you (or your AI assistant) can read and modify TypeScript far more confidently than Lua or XML configurations. - **The ecosystem works for you.** TypeScript's tooling — linters, formatters, testing frameworks, and IDE support — all work seamlessly with your gateway code. ## The bottom line TypeScript didn't become the #1 language on GitHub by accident. The convergence of AI coding tools and static typing created a flywheel that's reshaping how developers choose their stack. And that choice extends all the way down to infrastructure — including your API gateway. If your gateway forces you to write custom logic in Lua, Go, XML, or configuration YAML, you're fighting against the strongest trend in software development. You're choosing a language where AI tools are less effective, new hires are less productive, and code is harder to maintain. A TypeScript-native API gateway like [Zuplo](https://zuplo.com) lets you ride the wave instead of fighting it. Your gateway code lives in the same language as the rest of your stack, benefits from the same AI tooling, and follows the same patterns your team already knows. The AI era rewards developers who choose the right tools. For API gateways, that tool is TypeScript. Ready to build your API gateway in TypeScript? [Get started with Zuplo for free](https://zuplo.com) and see how TypeScript-native, AI-assisted API development works in practice.