---
title: "Apigee Needed a Simplification Tool. Zuplo Did Not."
description: "Google's new Apigee Feature Templater admits Apigee is too complex for non-experts. Zuplo's TypeScript-first API gateway was designed to be simple from the start."
canonicalUrl: "https://zuplo.com/blog/2026/04/08/google-open-sources-apigee-feature-templater"
pageType: "blog"
date: "2026-04-08"
authors: "nate"
tags: "API Gateway"
image: "https://zuplo.com/og?text=Apigee%20Needed%20a%20Simplification%20Tool.%20Zuplo%20Did%20Not."
---
Google just open-sourced the
[Apigee Feature Templater](https://github.com/apigee/apigee-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](https://discuss.google.dev/t/new-release-apigee-feature-templater-a-simplified-approach-to-proxy-authoring/294005)
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:

```typescript
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:

```json
{
  "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](https://zuplo.com/api-gateways/apigee-alternative-zuplo),
or read about how Zuplo handles
[custom policies in TypeScript](https://zuplo.com/docs/policies/custom-code-inbound).
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](https://zuplo.com/blog/2026/03/19/apigee-edge-end-of-life-migrate-to-zuplo).