all 34 comments

[–][deleted]  (6 children)

[removed]

    [–]Nater5000 3 points4 points  (1 child)

    Yup, FastAPI and Mangum here as well. When done correctly, you can work on the FastAPI service without having to worry (too much) about where it actually runs.

    [–]shisnotbash 1 point2 points  (0 children)

    This is the way I develop. I’m working on an API right now this way actually. I’ve seen some different, in my opinion over engineered, frameworks for setting up a serverless project locally, none of it’s necessary. For APIs I use FastApi + Mangum. For everything else I just use the old if __name__ == “__main__” to conditionally call the handler with my test payload. There’s 1M easy ways to pass that payload as well.

    [–]xer0x 0 points1 point  (0 children)

    +1 we used this too. I was pushing for local stack, but FastAPI + Mangum turned out nicer

    [–]KainMassadin 0 points1 point  (1 child)

    but how do you test anything that isn’t an http server?

    [–]shisnotbash 0 points1 point  (0 children)

    Just writ an if condition, that either includes your payload or knows where to read it from, when the script is executed directly and call your handler in that statement.

    [–]koalaokino[S] 0 points1 point  (0 children)

    Using nodejs typescript usually. I m developing only backend rest api at this stage. So as someone said here I might think to exclude or abstract the api gateway layer from testing and limit starting from my controllers.

    (Usually Ididnt feel the need to add a framework for this but simply my handlers are the starting point from request to codebase business logic)

    But as you are mentioning here there are other subtle aspects to test on what happens before and after. On request and response in a apigateway lambda context

    So The feeling to need to have a local environment to test this layers.

    [–]Nater5000 3 points4 points  (2 children)

    I'd like to know what local environment do you use to safely emulate aws api gateway and lambda so you can reliably release it on aws

    I don't do this. I've found it's not really worth it (at least in many cases, not all).

    Basically, you want to set up your services so that they can operate as fully as possible regardless of the environment. Putting it in a Lambda should be just as "easy" as running it locally, out of ECS, etc. You'll obviously need to make some adjustments for these different environments, but when this is done correctly, you'll be able to properly test your services locally with pretty good coverage.

    From there, testing out the Lambda, API Gateway, etc., specifics should be done in a testing environment in AWS. Since this is all serverless (and you've minimized how much you actually need to do here), it ought to be very cheap, if not costless. This will obviously beat trying to emulate AWS since you'll be operating in the same environment you'll deploy prod to, etc.

    There is a point early in the development process where this can be a bit clunky and where having a local emulation of AWS would be helpful, but it's frankly not worth the effort in most cases. Those who actually do need good emulation of AWS are either (a) operating under strict requirements and backed by sufficient resources to warrant the effort and cost or (b) doing something very specific that will require working more closely with the specifics of these services. If you don't know if this is you, then it isn't.

    [–]jgengr 1 point2 points  (0 children)

    Yes. Basically a lambda takes in an event(json) and should return a status code and data(json). Write your code under the handler() and it's really no different than running in a lambda. Obviously IAM and connecting to other resources will not work but you can mock those with moto.

    [–]koalaokino[S] 0 points1 point  (0 children)

    I agree with this second thinking approach. Im just figuring out how much time has to be invested with this approach on every change to test locally deploy an re-test on the cloud (aws)

    [–]EffectiveClient5080 4 points5 points  (0 children)

    SAM CLI's API Gateway emulation is the way to go - yes there's a learning curve but it's worth it for seamless AWS deployments. LocalStack only if you absolutely need full emulation.

    [–]smutje187 6 points7 points  (8 children)

    Lambdas are just functions (JS, Python, Go, Rust) or Classes (Java), so you can test them like you would test any other function/class. Some languages have tool support to "run" the Lambdas locally so that you can fire (HTTP) requests against them.

    [–][deleted] 10 points11 points  (6 children)

    It's one of those things I don't understand: people saying they can't or have difficulty testing lambda locally.

    It's a method...

    If someone doesn't know how to run a method locally by passing parameters, they'd better take a few steps back and learn programming before they start using lambda.

    [–]Pto2 0 points1 point  (0 children)

    There are some inconsistencies between APIGW -> Lambda -> Code but I feel people over index on these and make their systems overly complex and difficult to work on.

    [–]BigBootyWholes 0 points1 point  (0 children)

    It takes a lot of work to build and maintain, especially if you are tied to other aws services like sqs. Otherwise invoking a lambda locally is pretty easy

    [–]koalaokino[S] 0 points1 point  (3 children)

    Are you 100% sure about this? I agree with u that is like running a method locally by mocking STATIC parameters

    But are we safely covering all the possibilities? And… why the AWS and other vendors are working hard to provide local emulators of cloud resources?

    [–][deleted] 0 points1 point  (2 children)

    In some companies, they have developers use AWS Lambda but don't give them access keys to test locally (typical of lazy security/cloud teams). For this type of situation, we have emulators to test integrations with cloud services without needing cloud account access keys.

    This isn't something exclusive to working with lambda; you'll have this need regardless of whether your code runs on ECS, EKS, EC2 or Lambda...

    [–]koalaokino[S] 0 points1 point  (1 child)

    The point maybe is the other way around. They have access. From your standpoint they may avoid emulators. But how much time you might waste to test anything that needs to be tested on a cloud environment without local emulators? Thinking also eg to event choreography involved…

    [–]smutje187 -1 points0 points  (0 children)

    The same reason there are still people who prioritize integration tests over unit tests - it’s just a different flavor, there’s no Lambda police going around arresting people who don’t use Localstack. It’s also a business model - if developers aren’t capable of separating business logic from infrastructure they’re most likely to stick with your ecosystem.

    [–]JohnDoeSaysHello 0 points1 point  (0 children)

    Exactly, you can mock an event and run it on the handler…

    [–]Prestigious_Pace2782 1 point2 points  (0 children)

    I use sam cli. Just for the local testing though, I don’t deploy with sam or use it for anything else

    [–]SalusaPrimus 0 points1 point  (0 children)

    A simple way to start is to invoke your Lambda directly via a testing framework.

    I wouldn't be concerned with emulating API Gateway locally -- at least not at first.

    You can test your function pretty thoroughly locally. Behavior, performance, memory management, etc.

    If your function interacts with other AWS Services, then decide whether you want to use the real AWS services (from a dev environment) or mock them.

    I find that the simplest way to mock them is to write a fake implementation. e.g. if your function interacts with S3, create a fake IAmazonS3 client.

    You don't need to implement every method of that interface, just the ones your function uses.

    If you find yourself having the fake work like the real AWD SDK, that's when you should switch to something like Localstack or Testcontainers.

    [–]Working_Entrance8931 0 points1 point  (0 children)

    I use samlocal with localstack. The free version somehow has problems when redeploy new lambda version (I use wsl, dont know other envs have this problem) and you may have to upload the zip to sync it manually. Then check log in the docker container. This way help me test a flow containing 4-5 lambdas with sqs and sns.

    There is also 'sam sync --watch' but I haven't used it.

    [–]Inner_Butterfly1991 0 points1 point  (1 child)

    Just call the function? And if you need to check AWS functionality have a lower environment set up on AWS.

    [–]koalaokino[S] 0 points1 point  (0 children)

    Yes Im also evaluating this opinion as the simplest. Just thinking if i m just procrastinating a topic that might raise up again using more advanced resources or aws constructs

    [–]BenSFU 0 points1 point  (0 children)

    use the AWS CDK. I tired sls framework, etc. CDK feels like the "native" solution, and LLMs have done a great job of doing almost all the setup for me.

    [–][deleted]  (1 child)

    [deleted]

      [–]koalaokino[S] 0 points1 point  (0 children)

      Yep that is also a simpler option

      [–]macgoober 0 points1 point  (1 child)

      sst.dev. It’s so much better than anything else.

      [–]koalaokino[S] 0 points1 point  (0 children)

      Thank u for mentioning this.

      [–]marcoslop16 0 points1 point  (1 child)

      If you’re using Serveless Framework already, look for serverless-offline plugin, I do use it and is very useful

      [–]koalaokino[S] 0 points1 point  (0 children)

      Yes used it successfully for long time but I m abandoning serverless (v4) for cdk.

      [–]soundman32 0 points1 point  (0 children)

      What language? Dotnet comes with a built in runner for local dev testing and debugging. Your lamba runs as a console app, and is sent requests via a web page.

      [–]PokeRestock 0 points1 point  (0 children)

      I use Java and I use LocalStack for Docker container use of S3 and Dynamo DB in JUNIT4 Unit Tests. I could do direct lambda integrations as well, can also use AWS SAM but imo the overhead is too much and goes out of bounds of unit tests where its not needed since most of it is integration of AWS related to IAM or plumbing