Umbrella architecture

Aftermarket is one Go program, aftermarket, with a subcommand for each tool. Every tool lives in its own package and has its own tests. They share code only where two real tools need the same thing, such as the rule matcher or the audit log. If a tool ever needs to run on its own, it can be built as a separate binary from the same repository.

Where it sits

CLIENTS AND INTEGRATIONS (unchanged)
          |
          v
   aftermarket
   patch  | fix requests and responses
   adapt  | translate old APIs to new ones
   record | capture traffic as test fixtures
   replay | compare two versions of a service
          |
          v
APPLICATION / API / SERVICE (unchanged)

patch shipped in 0.1.0. The other commands are planned in the order shown on the roadmap.

AfterPatch, the first tool

AfterPatch is a small reverse proxy. It matches HTTP traffic against explicit conditions and applies limited changes to the request or the response. Rules are YAML, short enough to read in a code review. A rule looks like this, and the reference has the full format:

rules:
  - id: restore-customer-id
    when:
      method: GET
      path: /v2/customers/*
      content_type: application/json
    response:
      json:
        - copy: {from: customer.id, to: customer_id}

Every request goes through the same steps: receive, match, change, forward, record. In dry-run mode the proxy forwards traffic untouched and only reports what it would have changed. Rules always apply in the same order, so the same input gives the same output.

Some limits are part of the design from day one:

  • a body size cap, above which traffic passes through unchanged
  • correct handling of chunked and compressed bodies
  • timeouts on the upstream service
  • secrets removed from the audit log
  • a health check endpoint

Traffic that no rule matches is passed on byte for byte. The test suite checks that on every run.

What stays out

No scripting language inside the rules. No central control plane, no plugin marketplace, no cluster mode. A rule should do one visible thing, and a person should be able to see from the audit log exactly what it did.