Call your java based lambda functions within milliseconds via HTTP API with on-the-fly debugging capabilities.
LambdaProxy launches a tomcat servlet that reads the API description from your template.yaml. When it receives
an HTTP request, it calls the respective lambda function directly by passing the required event. Each lambda function is loaded in its
own isolated ClassLoader so there is minimum interference between different lambda functions or with LambdaProxy itself.
Like when executing lambda functions in AWS, each lambda instance is kept alive until it wasn't used for at least five minutes, resulting in very short response times of your API. As LambdaProxy is just a regular Java servlet, you can debug your Lambdas at any point in time by using the remote debugger agent.
Build your lambda application using sam build which should compile everything into .aws-sam.
Build LambdaProxy using maven:
mvn clean package
If you don't want to compile LambdaProxy yourself, just download the latest release from here. You can then run LambdaProxy by providing the directory of your build lambda function:
java -jar ./target/LambdaProxy-1.0-SNAPSHOT.jar ~/Workspace/my-lambda-function
If you want to debug your lambda function, add the remote debugger agent:
java -agentlib:jdwp=transport=dt_socket,server=y,address=5858,suspend=n -jar ./target/LambdaProxy-1.0-SNAPSHOT.jar ~/Workspace/my-lambda-function
When you rebuild your lambda function, LambdaProxy will automatically pick up the changes and reload the API.
sam local start-api is great, but it has a few shortcomings: First of all, it is comparably slow. Whenever a new API resource
is called sam local start-api spins up a new Docker container to invoke the requested function. As a result, invoking
a single API method can require about a second, even on adequately equipped developer machines. If you’re using the
local API e.g., to test a frontend application that performs a substantial amount of API calls, this can become a bit annoying.
The second shortcoming is the step-by-step debugging. You can enable step-by-step debugging using the -d flag, but this will
cause sam to wait on every single API invocation until a debugger is attached. So again, if you’re working on a frontend
application that performs various API requests, this can quickly become tedious. Unlike debugging a regular Java
application, you cannot just let your application run and just put a breakpoint in on-demand during testing.