aws-lambda-python-runtime-interface-client VS aws-lambda-runtime-interface-emulator

There is an AWS provided runtime client that will probably work with Python 3.11, but if not the API is small enough to roll your own. Or generate one with the OpenAPI Spec they provide.

Let's see what's happening here. We initiate a multi-phase build to reduce the size of our final image. On the FROM lines we choose which Python version we want to use for our runtime. If you wanted to work with Python 3.10 then you could simply replace the 3.11 part with 3.10. As a last step of the first build phase we install awslambdaric, which is the AWS Lambda Runtime Interface Client which makes sure that the Lambda environment is able to communicate with our own code. In the 2nd stage we simply copy the runtime interface client into our final image.

Yep. In fact, I recently had to deal with this monstrosity https://pypi.org/project/awslambdaric whose setup.py invokes a shell script https://github.com/aws/aws-lambda-python-runtime-interface-c...

That shell script runs 'make && make install' on a couple of bundled dependencies, but in principle it could do anything https://github.com/aws/aws-lambda-python-runtime-interface-c...

AWS has open-sourced some of the Lambda runtimes you might be using on a day-to-day basis. You can find the Go, Python and Node Lambda runtimes on their GitHub. I encourage you to go out and explore those repositories. There is much to learn about how the code you are writing and deploying is run.

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.