18nleung

Author here. Wrote a bit about how we use Terraform for local dev at work. In brief:

Our Docker Compose local dev setup started to break down once we had to model more complicated production behavior locally – things like table-specific Postgres roles for audit logs and dynamically provisioned databases per-clinical-trial. We were drifting toward a bespoke Bash mess to keep dev and prod in sync.

Our core idea was instead to embrace Terraform in the local dev environment too. We were already using Terraform heavily in prod, and Terraform's robust provider ecosystem meant that we could e.g. substitute Docker containers for RDS and MinIO for S3 without deviating too far from our production configuration.

The really fun part is how we use Terraform to handle dynamic provisioning, which we need for isolated, per-clinical-trial databases. The way we do it in prod is by giving each clinical trial its own, isolated Terraform state, stored in a cloud storage bucket. By writing an equivalent local Terraform config for this provisioning step, we enable the app to run the same `terraform apply` command as it does in prod to locally to spin up a new database, with the individual state for that new db stored in a local MinIO bucket... which is itself created by the original `terraform apply` that sets up the initial local dev infrastructure.

Altogether, Terraform gives us a super high-fidelity local environment that lets us test complex application behavior and infrastructure logic without the full overhead of spinning up a local k8s cluster (which is what I imagine the next best alternative might be?). It's readable, declarative, and required no new tooling on our side since we were already using Docker and Terraform anyways.

Curious to hear how other folks are managing complex local dev setups, especially if you're not on Kubernetes!

I would have written a shorter source, but I did not have the time.

You're right that IDE/dev-time performance might be slower than using generated types since this relies on "dynamic" TypeScript inference rather than static codegen'd types.

That said, depending on how your codegen works and how you're using protos at runtime, this approach might actually be faster at runtime. Types are stripped at compile-time and there’s no generated class or constructor logic — in the compiled output, you're left with plain JS objects which potentially avoids the serialization or class overhead that some proto codegen tools introduce.

(FWIW, type inference in VSCode seemed reasonably fast with the toy examples I was playing with)

I biked with the author from SF to Sacramento — we went up to Marin over GGB, then over the Richmond–San Rafael bridge to the EB