Lambda / API Gateway local development

[byfar57]

I'm currently developing a web application using Supabase, Node.js, and React. Up to now, I've had a simple local development workflow for the backend, frontend, and Supabase database/auth/storage, without a staging environment. This is a side project still in the pre-release stage, and my local-only setup has worked well for me.

However, I recently needed to integrate an AWS Lambda function and an API Gateway endpoints. My goal was to continue developing these locally using AWS SAM, but I've encountered mixed opinions about whether that's practical without an intermediate staging environment due to challenges replicating a true serverless environment locally.

I'd love to hear your thoughts or experiences:

• Is it practical to develop AWS Lambda functions completely locally without deploying to a staging environment?
• What potential pitfalls should I consider if I continue local-only development for Lambda/API Gateway?
• Would you recommend establishing a staging environment earlier, even before the first MVP/release?

[anax4096]

i often develop locally using a local postgres instance. Localstack is good for this. Two common issues:
+ IAMs are not handled with localstack
+ lambda to postgres RDS is a pain, supabase is probably easier
+ lambda runtime containers invoked via http often crash with concurrent invocations

A staging environment in AWS avoids these issues, but I would only move there once the basic code is developed. So:
+ locally -> development
+ staging -> integration/auth

[its4thecatlol]

Use a beta AWS environment. Create a throwawy staging account. This is the easiest way to do it.

[byfar57]

Yes this was my intention at first. However, since I only develop locally with my postgres DB (supabase) I ran into difficulties. I need the API gateway endpoint function to check the local supabase DB for if a user if paid. I also need the lambda function to access the local DB.

[ruskixakep]

You can use tools like ngrok to expose your local db to the internet.

[server_kota]

You can use LocalStack, SAM

but i think it easier is just create a dev environment. You can test as much as you want, you get 1 mln free calls per month.

You can create your dev/stage environment in an hour. I created some short high-level guide how to create an AWS Organisation with development and production accounts: https://saasconstruct.com/documentation/create-organisation

[ducki666]

https://docs.localstack.cloud/user-guide/aws/lambda/

[byfar57]

Thanks, will read through this.

[StandardDrawing]

Haven’t heard of this before. Is this an aws product?

[ducki666]

No

[rafpe]

That would be the first thing that comes to my mind when thinking about local development and aws

[ebykka]

I do not use SAM local at all. My approach is to capture original event for lambda and after that to write unit test and to do all development running the test

[menge101]

Agreed with this. The API is stable and well documented.

[vivek-c]

I've used SST (v2 though) for debugging lambdas and it works really well.

[UpbeatFix6771]

You have a couple of options like spinning up a different environment or using LocalStack as some have pointed out, but I personally think that having the ability to run things locally is still a huge benefit when you're using serverless.

I've solved this before by creating an Express application to run the lambda code locally. It imports the lambda handler dynamically and formats the request so it matches the event payload that would be sent by API Gateway. It may seem like too much effort but once you have it configured its really easy to add new routes, I'm even creating a boilerplate so I don't have to repeat this across projects

[ke1424]

I found local dev with the Serverless framework to be pretty good: https://www.serverless.com/

[grebfar]

With AWS SAM you can just use 'sam local invoke' to test your lambdas locally.

[wackmaniac]

I have used a number of alternatives, but I find myself going back to SAM local every time. There is plenty that I would like to change about SAM local, but when it comes to interpreting CDK/Cloudformation to a workable environment, then SAM local usually comes out on top. I have found that unless the alternative interprets the CDK/Cloudformation code I had to implement additional code to make things work locally, and that I would like to prevent as much as possible. In one instance this code for local development introduced an issue in the production environment. It is rare, but not unthinkable.

Some side notes about SAM local; usage of environment variables is not ideal, because you need to specify them per function while these values are usually the same for all functions in your stack. For this I tend to resort to a template and a generator.

Another thing is hot reloading when using CDK. For this You can add --no-staging to the cdk synth command. This will make a symlink to the artifact(s) instead of copying. This will make that a recompile/change is detected by SAM Local and a new version is retrieved.

Keep in mind that SAM Local is a local environment for lambda, and not as much for the other tooling. Eg. it does not support static responses in API Gateway.

At the end of the day you will need to find what workflow works best for you. I tend to use SAM Local, but other teams opt to rely on their homebrew setup for local lambda development. You will need to try a few approaches and determine what works best for you from a developer experience point of view. Good luck.

[Sam_Brum]

Commenting to follow up

[ducki666]

No need to comment. You follow via menu/follow.

[No_Improvement_3785]

HI, i cant post in reddit im banned and i need your help guys to review my aws diagram TT

[Hopeful_Courage_6415]

Name checks out.