My code is written to capture errors and log out useful error messages if an issue occurs. If I am testing against an exact replica of production I may as well make my error management as expressive as it would be for production. You can't breakpoint production and still need to debug if an issue occurs:
try{//Do something here that may error out}catch(error){console.log('An error occurred')console.log(error)returnerror}
I mean, we have incredible ides and debugging tools available. It'd be a huge loss to just not use them for anything at all anymore.
Why not just spin up duplicate cloud resources for development, and connect to those for local development? It solves the issue of mocking the cloud resource, without sacrificing any of the development tooling.
Maybe I misunderstood in your article, but people aren't really running mysql or redis locally, are they? It's just as easy to have pared down dev versions running in aws. I use scheduled batch scripts to turn them on/off each day, so they don't cost anything when nobody would be using them, and are fully up and running when they would be needed (so there's no waiting for it to spin up).
The only really challenging thing is event-driven. There's close to no examples of what an SQS payload looks like when triggered from S3 (for example), so creating a dummy lambda just to log the message, so you can mock it locally, seems to be the only way to start a project that consumes those events. But running the whole project in the cloud wouldn't solve that issue, either.
For some things it can make sense. But how do you do basic debugging, like setting a breakpoint?
My code is written to capture errors and log out useful error messages if an issue occurs. If I am testing against an exact replica of production I may as well make my error management as expressive as it would be for production. You can't breakpoint production and still need to debug if an issue occurs:
I mean, we have incredible ides and debugging tools available. It'd be a huge loss to just not use them for anything at all anymore.
Why not just spin up duplicate cloud resources for development, and connect to those for local development? It solves the issue of mocking the cloud resource, without sacrificing any of the development tooling.
Maybe I misunderstood in your article, but people aren't really running mysql or redis locally, are they? It's just as easy to have pared down dev versions running in aws. I use scheduled batch scripts to turn them on/off each day, so they don't cost anything when nobody would be using them, and are fully up and running when they would be needed (so there's no waiting for it to spin up).
The only really challenging thing is event-driven. There's close to no examples of what an SQS payload looks like when triggered from S3 (for example), so creating a dummy lambda just to log the message, so you can mock it locally, seems to be the only way to start a project that consumes those events. But running the whole project in the cloud wouldn't solve that issue, either.
If you're looking to set breakpoints and debug Lambda functions locally checkout SST — github.com/serverless-stack/server...
It connects directly to what's been deployed on AWS without mocking or emulating them.
Oh now that looks exciting. Thanks :)
Check out lightrun.com in that case... Get literally the experience of a local debugger in production environment (I work there).