HackerTrans
TopNewTrendsCommentsPastAskShowJobs

18nleung

no profile record

Submissions

Building audit logging in Postgres without triggers

runharbor.com
3 points·by 18nleung·2 ay önce·0 comments

Notes on YC P26, halfway through the batch

natecation.com
2 points·by 18nleung·2 ay önce·0 comments

NPM website was down

status.npmjs.org
126 points·by 18nleung·3 ay önce·61 comments

Naming rights to street auctioned in San Francisco

paintastreet.com
21 points·by 18nleung·3 ay önce·16 comments

How We Model Clinical Trial Data When Every Trial's Data Model Is Different

runharbor.com
2 points·by 18nleung·4 ay önce·0 comments

Why We Love Functional Programming But Don't Use Effect-TS

runharbor.com
2 points·by 18nleung·7 ay önce·0 comments

Using Atomic State to Improve React Performance in Deeply Nested Component Trees

runharbor.com
10 points·by 18nleung·9 ay önce·1 comments

Using Terraform in *Local* Dev for Reproducible, High-Fidelity Dev Environments

runharbor.com
3 points·by 18nleung·9 ay önce·3 comments

Show HN: Terraform for *Local* Dev Infra

runharbor.com
2 points·by 18nleung·10 ay önce·0 comments

comments

18nleung
·9 ay önce·discuss
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!
18nleung
·9 yıl önce·discuss
This sounds like a good use case for Promise.all() and fetch:

  const first = fetch(endpoint1);
  const rest = Promise.all([
    fetch(e2), fetch(e3), fetch(e4),
  ]);
  // cancel here
  const json1 = await first.json();
  const json234 = await rest.json();
While native promises can't cancel on their own, with a library like Bluebird you can get that functionality.