Home

It is time to rebuild the GasBuddy service infrastructure. The next generation of the infrastructure should address the following issues:

1. Originally, flow and TypeScript were both unknown quantities. The tooling wasn't very good and it wasn't clear which one would win. We experimented with Flow, but it never stuck, and it turned out not to be the winner. Our new infrastructure should be TypeScript based.
2. To make TypeScript work, it's likely that we should move away from config-based object creation and just be declarative in code. Confit works well to merge environment-based files with defaults and shortstop handlers are useful for building complex values. But the "hydration" infrastructure should probably be retired. Instead, classes and/or functional composition should be employed. Practically, it is no harder for us to change server-code.js than to change config.json.
3. We should support serverless infrastructure, meaning it should not be assumed that there will be a lengthy "startup process" for our foundational components. We will still have Kubernetes pods for a number of components, but others, such as api services, probably should move to serverless.
4. Our React SSR infrastructure is a bit dated, and we should consider whether Next.JS is worth adopting, given that the points above should make it possible to do so.
5. We built our own tracing infrastructure. It would be nice to use some protocol that is compatible with our existing log pipeline but also compatible with zipkin or opentrace or some such.
6. Our logging, metrics and tracing are very custom, very heavy (maintenance especially, but storage too) and fairly hodge podge (partly as a result of the hydration). It also makes it hard to have "open source" modules that don't rely on all that custom stuff. We should move to OpenTelemetry. It's not perfectly clear yet whether and how we continue to use Pino (which has OpenTelemetry support).
7. Tap seems to be out of favor as a testing platform in favor of Jest (which we use in web and React Native as well). We should probably move to Jest. It's unclear to me whether test-next-to-code is always the right thing, but in most cases that probably makes sense.

Sequence

I've sat down a few times to rewrite a package or two in TypeScript and quickly end up down the rabbit hole changing five other things. To get over the hump, we need two things - an agreed upon order of attack, and more than one person working on it. This is a wiki page, so edit as desired, but the current roadmap:

1. Agree upon a TypeScript setup via generator-gasbuddy and lint/prettier configs
2. Process all the "configured-xyz" modules to figure out which ones are necessary and which ones can go away in favor of direct module access and which still perform some valuable service in a more declarative context.
3. Rewrite this service module from scratch (copying as necessary) to be able to start an express service with logging, configuration management and whatever else is worth keeping.
4. Write a service and deploy it, making sure we have logging and tracing working and a plan for cutting over