Umbrella development plan

Status: 0.1.0 released. Each release ships only when its tests pass on Linux and macOS, and every number on this site comes from recorded test results.

Decisions made

  • One program. A single aftermarket binary with a subcommand per tool. A tool gets its own binary only if it proves it needs one.
  • One repository. The code lives at github.com/aftermarket-dev/aftermarket, written in Go.
  • One rule style. Every tool uses the same YAML when: block to match traffic. The actions after it belong to each tool.
  • Open source. Apache 2.0.
  • A real test case. The old-client, new-API customer example from the introduction is the fixture the first releases are tested against.

0.1.0: AfterPatch (released)

A reverse proxy with YAML repair rules. It matches on method, path, query, headers, status code and content type. It can set or remove headers, rewrite paths, and rename, copy, set or delete JSON fields in requests and responses. It also has a dry-run mode, an audit log with secrets removed, a command that checks a rule file, and a command that runs a rule against a saved request and response.

The tests aim at the main promise, which is that a rule repairs one thing and breaks nothing else. Traffic no rule matches must come out byte for byte. Broken, oversized, compressed and chunked bodies must pass through safely. A slow or dead upstream must produce a clean error. And the example client must fail without its rule and work with it.

0.2.0: AfterAPI

An aftermarket adapt command for bigger translations: moving endpoints, rebuilding request and response bodies, and mapping headers. After this release there’s a decision on whether AfterAPI stays a subcommand or becomes its own tool.

0.3.0: AfterTest and AfterDiff

aftermarket record captures traffic through the proxy into fixture files, with sensitive data removed. aftermarket replay sends those fixtures to two versions of a service and reports the differences. Together they turn every repair rule into one that has been tested against real traffic.

After that

The next tool gets picked by what users actually need, not by filling in names. AfterGuard fits naturally on the proxy and needs a written threat model first. AfterHook and AfterConfig are simpler and can stand alone. AfterSchema and AfterBridge need a specific target system to be useful.

Afterlife and AfterTrace stay research for now. Afterlife will only ever replace documented APIs. AfterInstall, AfterDocs, AfterMock, AfterDeploy, AfterUpgrade and AfterPlugin are ideas, and listing them here isn’t a promise to build them.