serverless-offline VS aws-lambda-runtime-interface-emulator

Using local emulators like sam local, serverless-offline, localstack, etc.

Hi, I'm the creator of serverless-offline (https://github.com/dherault/serverless-offline), a NPM package for local serveless development on AWS.

I'm building a cool product and intend to launch Q1 2023. To gain traction from my target customers, I plan to place a discrete ad at the launch of every serverless-offline instance.

Does it seem like an ok move to you? Or is it something that repels you?

Best,

As the creator of serverless-offline, I am well placed to tell you that this is the time-effective solution. Plus, it costs way less than other solutions at smaller scales. But, again, going Kubernetes or otherwise will be a problem for the future.

https://github.com/dherault/serverless-offline https://github.com/lambci/docker-lambda

What if I didn’t need to push code to AWS every time I wanted to test something? All heroes don’t wear capes. Like a knight in shining armor, Serverless Offline comes barging in to save the day! At least now I can test all my code locally before pushing it to AWS. That’s a relief.

With classic Express servers, you can use a simple node script to get the server up and running to test locally. Serverless wants to be run in the AWS ecosystem making it. Lucky for us, David Hérault has built and continues to maintain serverless-offline allowing us to emulate our functions locally before we deploy.

With the serverless offline plugin you can speed up local dev is by emulating AWS lambda and API Gateway locally when developing your Serverless project.

Those mocks are by definition not real services so there are some behavior differences between the local environment and the cloud provider. For example, AWS API Gateway emulated by serverless-offline doesn't handle VTL locally the same as AWS does.

serverless-offline (https://github.com/dherault/serverless-offline) is a great tool to use for local development of serverless applications.

It's not a complete mirror image of what you get but it's close enough in my experience.

Enter the aws-lambda-runtime-interface-emulator. This tool will allow us to emulate the AWS Lambda Runtime API locally (I suspect that the AWS SAM uses this tool under the hood as well). The aws-lambda-runtime-interface-emulator is designed to be used with Docker. Still, nothing stops us from containerizing our code for the sake of development and then, whenever we are ready, proceeding with deployment how we wish to. This local workflow is a bit more involved than the previous one, but it might be a valid alternative for those not using AWS SAM or are already using containers to deploy their Lambdas.

There is a special tool to test AWS Lambda images locally. It's called AWS Lambda Runtime Interface Emulator (RIE). You have two options: include RIE in your image or install it locally. We don't need it in the production image, so let's choose the second option. We will download binary locally and mount it to our image if we need to test it.

Suggestions:

1. If you are building APIs and using Lambda functions as targets from an API Gateway API, look into libraries like serverless-wsgi (Python) or wai-handler-hal (Haskell) that translate between API Gateway request/response payloads and some kind of ecosystem-native representation. Then as long as you're writing code where all state gets persisted outside of the request/response cycle, you can develop locally as if you were writing for a more normal deploy environment.

2. Look into the lambda runtime interface emulator ( https://github.com/aws/aws-lambda-runtime-interface-emulator... ). This lets you send invoke requests to a fake listener and locally test the lambda more easily. While the emulator is provided in the AWS container base images, you don't need to run it inside a container if you're deploying with zip files. (AWS-provided container images automatically enable the emulator if not running in a lambda runtime environment, and using docker for port remapping is nice. But not at all required.)

3. Get really good at capturing all requests to external services, and mocking them out for local testing. Whether this is with free monads, effect systems, gateway classes will depend on your language and library choices.