You should not be using AWS. Probably.

Re:You should not be using AWS. Probably. by friendly_deer on Friday October 14, 2022 @10:30AM (#33203982)

The thing that holds me back from Google cloud run Is that it is difficult to replicate that exact environment locally for testing and dev. If you’re working with stateless apps then that’s fine, But what is the typical local workflow of developing against a database, task Queue, etc.?

[ Parent | on HN ]

Re:You should not be using AWS. Probably. by CharlieDigital on Friday October 14, 2022 @10:51AM (#33204311)

Which database?

If you're going all-in on Google Cloud and using Firestore, then use the emulators [0]. The emulators includes Pub/Sub. For Cloud Task Queues, use an unofficial emulator [1]

If you're not going all-in on Google Cloud and say you want to use Postgres, then use a `docker-compose.yaml` file and pull in a Postgres container instance or run a local Postgres if you want. Then pick a free Postgres compatible cloud service for the actual runtime (e.g. Supabase free tier). Same goes for MySQL.

For AWS, I'd use LocalStack [2]

[0] https://github.com/CharlieDigital/dn6-firebase

[1] https://github.com/aertje/cloud-tasks-emulator

[2] https://localstack.cloud/

[ Parent | on HN ]

Re:You should not be using AWS. Probably. by friendly_deer on Friday October 14, 2022 @01:20PM (#33206363)

Thank you for the reply. That makes sense… I guess something about me just likes the purity of running the exact same container on my local machine as would be in prod, but yeah I agree that at some scale that doesn't work.

[ Parent | on HN ]

Re:You should not be using AWS. Probably. by nijave on Friday October 14, 2022 @11:41AM (#33205032)

If you're using an IaC tool like Terraform or Pulumi, you can just setup/tear down test resources on demand (for integration/acceptance tests). Under normal usage, hopefully you can get away with mocks/stubs/fakes. Some development frameworks make this a lot easier than others

Using real resources is usually fine for smaller applications but can be very problematic as your application grows. With that in mind, it's good to create boundaries so you limit the amount of "real infrastructure" you need to test/deploy. Reference https://martinfowler.com/bliki/IntegrationTest.html

[ Parent | on HN ]

Re:You should not be using AWS. Probably. by friendly_deer on Friday October 14, 2022 @01:23PM (#33206400)

Thanks for taking the time to reply. Yeah ideally we always use real resources to mirror prod closely, but I see your point that that won’t always be possible as the app grows.

[ Parent | on HN ]

Re:You should not be using AWS. Probably. by nijave on Friday October 14, 2022 @04:26PM (#33208430)

Another balance is to just use real resources in CI with some concurrency control to make sure a single build runs at once. Locally, you continue to use mocks/stubs/fakes

You still get assurance from testing but reduce the amount of places you run the "expensive" (time, resource, $) tests

[ Parent | on HN ]