Apigee Needed a Simplification Tool. Zuplo Did Not.

Google just open-sourced the Apigee Feature Templater (AFT), a CLI tool that wraps Apigee’s complex XML policy system in YAML templates so that non-experts can compose API proxies without mastering the underlying configuration. The motivation is telling: Google says that while Apigee is “incredibly powerful,” it has “a learning curve that can be difficult for non-Apigee experts to master.”

That’s a polite way of saying Apigee is too hard to use.

What the Apigee Feature Templater does

AFT introduces three abstractions on top of Apigee’s existing policy model:

• Features — reusable building blocks that encapsulate one or more Apigee policies, resources, and parameters
• Templates — YAML blueprints that compose multiple features into a complete API proxy definition
• Proxies — the final deployable packages generated from templates, ready to push to Apigee

The workflow looks like this: an Apigee expert creates a feature (say, OAuth 2.0 validation or PII masking), packages it with the right XML policies and configuration, and publishes it. Then a less experienced developer assembles those features into a template using a YAML file and deploys it with a single CLI command.

It’s a clever solution to a real problem. But the problem itself is worth examining.

The problem isn’t the tooling — it’s the model

AFT exists because Apigee’s proxy authoring model is built on XML policy configurations that require specialized knowledge to write, debug, and maintain. As the announcement on Google Developer forums acknowledges, Apigee expertise remains a specialized skill that requires detailed knowledge of all the policy types and their attributes.

So Google’s answer is to add another layer: YAML templates on top of XML policies, managed by a CLI tool. The expert still writes XML. The non-expert writes YAML that references the expert’s XML. The complexity doesn’t disappear — it gets hidden behind a new abstraction.

This pattern is familiar in enterprise software. When a tool is too complex for its users, you build a tool to simplify the tool. The question is whether the right answer is more tooling or a fundamentally simpler model.

TypeScript instead of abstraction layers

Zuplo took a different approach from the start. Instead of building a powerful but complex policy engine and then layering simplification tools on top, Zuplo uses TypeScript — a language that millions of developers already know — for all gateway logic.

A custom inbound policy in Zuplo is a TypeScript function:

import { ZuploRequest, ZuploContext } from "@zuplo/runtime";

export default async function (
  request: ZuploRequest,
  context: ZuploContext,
  options: { allowedOrigins: string[] },
  policyName: string,
) {
  const origin = request.headers.get("origin");
  if (!origin || !options.allowedOrigins.includes(origin)) {
    return new Response("Forbidden", { status: 403 });
  }
  return request;
}

No XML. No YAML templates. No CLI tool. Just a function that takes a request and returns either a modified request (to continue the pipeline) or a response (to short-circuit it). The runtime uses Web Standard APIs — Request, Response, Headers, fetch — the same primitives developers use in every modern web application.

Routes are defined in an OpenAPI-based JSON config, and policies are wired up declaratively:

{
  "paths": {
    "/api/v1/orders": {
      "get": {
        "x-zuplo-route": {
          "handler": {
            "export": "urlForwardHandler",
            "module": "$import(@zuplo/runtime)",
            "options": {
              "baseUrl": "https://your-backend.example.com"
            }
          },
          "policies": {
            "inbound": ["api-key-inbound", "rate-limit-inbound"]
          }
        }
      }
    }
  }
}

Everything lives in Git. Every change goes through a pull request. Deployments happen in seconds. There’s no separation between “expert” and “non-expert” developers because the configuration language is the language your team already uses.

The real difference

The Apigee Feature Templater is Google’s acknowledgment that Apigee’s policy model creates a two-tier developer experience: experts who can write the XML, and everyone else who needs to be shielded from it. AFT bridges that gap with another layer of abstraction.

Zuplo doesn’t have that gap to bridge. When your gateway logic is TypeScript and your configuration is JSON, any developer on the team can read it, write it, review it in a PR, and deploy it. You don’t need a templating tool because the configuration was designed to be accessible in the first place.

If you’re evaluating API management platforms — especially if you’re already feeling the complexity of Apigee — it’s worth looking at what’s possible when simplicity is a design principle rather than an afterthought. Check out our detailed comparison of Zuplo vs. Apigee, or read about how Zuplo handles custom policies in TypeScript. And if you’re dealing with the Apigee Edge end-of-life timeline, we’ve written about why migrating to Apigee X isn’t your only option.