3 ms·

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 wi

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.?

CharlieDigital 4y ago
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 https://github.com/CharlieDigital/dn6-firebase [1] https://github.com/aertje/cloud-tasks-emulator https://github.com/aertje/cloud-tasks-emulator [2] https://localstack.cloud/ https://localstack.cloud/
- friendly_deer 4y ago
  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.
nijave 4y ago
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 https://martinfowler.com/bliki/IntegrationTest.html
- friendly_deer 4y ago
  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.
  - nijave 4y ago
    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

CharlieDigital 4y ago

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 https://github.com/CharlieDigital/dn6-firebase [1] https://github.com/aertje/cloud-tasks-emulator https://github.com/aertje/cloud-tasks-emulator [2] https://localstack.cloud/ https://localstack.cloud/

friendly_deer 4y ago
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.

nijave 4y ago

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 https://martinfowler.com/bliki/IntegrationTest.html

friendly_deer 4y ago
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.
- nijave 4y ago
  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