Introduction

Cars have an aftermarket. Replacement parts, upgrades, independent repair shops and specialist suppliers keep a car useful long after it leaves the factory, and none of them need the manufacturer’s permission. Software has the same kind of ecosystem. It’s just scattered across plugins, patches, extensions, compatibility layers, migration scripts and monitoring agents, and nobody calls it by one name.

Aftermarket.dev gives that work a name and a set of tools. Each tool adds something to software after it has been built, deployed, sold or abandoned, and none of them touch the original source code.

The scope is deliberate. These tools are for applications, APIs and services whose code you can’t change, or would rather leave alone. They ship as one aftermarket program with a subcommand per tool, from one code repository at github.com/aftermarket-dev/aftermarket, under the Apache 2.0 licence.

The first tool is AfterPatch, because a small HTTP repair is easy to show and easy to test. The rest of the family is on the concepts page, and the roadmap shows the order they’re built in.

One problem, one repair

Say an old client calls /api/v1/customer. The service it talked to has been replaced. The new one answers at /api/v2/customers/{id} and returns its JSON in a different shape. Nobody can rebuild the client.

An Aftermarket rule can translate the request, call the new API and put the old response shape back together. The client and the new service both stay as they are. That’s the kind of concrete, testable result the project is after, and it’s the exact case the first tests are built around.

Status: AfterPatch 0.1.0 is out. Get it from the download page, or try the example in the quick start.