Summary
`adc` supports three backends: `apisix` (cluster mode), `api7ee`, and `apisix-standalone` (single-node, config-via-API). The standalone backend in adc ships with a per-instance cache layer that tracks the last-known full config so subsequent syncs can skip the full "PUT every resource" cycle when nothing changed.
a7 currently targets API7 EE only. This issue asks: do we want a7 to also drive standalone APISIX, and if so, do we need the cache?
Context
- adc cache implementation lives in `adc/libs/backend-apisix-standalone/src/` and tests in `adc/libs/backend-apisix-standalone/e2e/cache.e2e-spec.ts` (~440 lines).
- The cache exists because standalone APISIX accepts the entire config as one PUT; without a cache, every sync re-uploads everything even when there are no diffs.
- API7 EE has a real Admin API with per-resource endpoints, so a7 doesn't need this cache today.
Two questions
1. Should a7 support standalone APISIX at all?
Arguments for:
- broader user base — community APISIX users could share tooling with API7 EE users,
- matches `adc` feature parity exactly,
- standalone is the easiest way to demo a7 (no etcd cluster).
Arguments against:
- a7 is positioned as the "official API7 EE CLI"; widening scope blurs the product story,
- maintenance cost — every `config` subcommand grows a per-backend branch,
- the multi-backend abstraction in adc is non-trivial (per-backend resource transformations, separate validation paths).
2. If yes to (1), how is the cache stored?
Options:
- on-disk under `~/.config/a7/cache/{backend-id}.json` keyed by gateway-group/server URL,
- in-memory only (no skip on subsequent runs — defeats the point),
- never cache — always upload full config (simple, but loses the perf win).
Why deferred
Identified during the adc → a7 test parity audit (see `docs/adc-test-parity-plan.md`). Unlike the other deferred items, this one is scope-first, not work-first — we need a product call before any code is meaningful.
Definition of done
A documented decision (in `AGENTS.md` or `docs/`) on:
- whether a7 will support apisix-standalone (yes / no / future),
- if yes, the cache strategy and any user-visible CLI changes (`--backend` flag, etc).
If "no", close this and remove the corresponding `[N]` entries from the test-parity plan as out-of-scope rather than gaps.
Summary
`adc` supports three backends: `apisix` (cluster mode), `api7ee`, and `apisix-standalone` (single-node, config-via-API). The standalone backend in adc ships with a per-instance cache layer that tracks the last-known full config so subsequent syncs can skip the full "PUT every resource" cycle when nothing changed.
a7 currently targets API7 EE only. This issue asks: do we want a7 to also drive standalone APISIX, and if so, do we need the cache?
Context
Two questions
1. Should a7 support standalone APISIX at all?
Arguments for:
Arguments against:
2. If yes to (1), how is the cache stored?
Options:
Why deferred
Identified during the adc → a7 test parity audit (see `docs/adc-test-parity-plan.md`). Unlike the other deferred items, this one is scope-first, not work-first — we need a product call before any code is meaningful.
Definition of done
A documented decision (in `AGENTS.md` or `docs/`) on:
If "no", close this and remove the corresponding `[N]` entries from the test-parity plan as out-of-scope rather than gaps.