AWS Lambda Function Handler
The AWS adapter takes a Spring Cloud Function app and converts it to a form that can run in AWS Lambda.
AWS Request Handlers
As discussed in AWS Serverless Java container, AWS Lambda functions are invoked at a predefined entry point, called the Lambda function handler.
When a Lambda function is invoked, it passes an additional request payload and context object to this handler method. The request payload varies based on the AWS service (Amazon API Gateway, Amazon S3, Amazon SQS, Apache Kafka etc.) that triggered the function. The context object provides additional information about the Lambda function, the invocation and the environment, etc.
AWS provides predefined handler interfaces (called RequestHandler or RequestStreamHandler) to deal with payload and context objects via the aws-lambda-java-events and aws-lambda-java-core libraries.
Spring Cloud Function already implements these interfaces and provides a org.springframework.cloud.function.adapter.aws.FunctionInvoker to completely abstract your function code from the specifics of AWS Lambda. This allows you to just switch the entry point depending on which platform you run your functions.
Type Conversion
A benefit of leveraging the built-in FunctionInvoker is that Spring Cloud Function will attempt to transparently handle type conversion between the raw input stream and types declared by your function.
For example, if your function signature is Function<Foo, Bar> it will attempt to convert the incoming stream event to an instance of Foo. This is especially helpful in API-triggered Lambda functions where the request body represents a business object and is not tied to AWS specifics.
If the event type is not known or can not be determined (e.g., Function<?, ?>) Spring Cloud Function will attempt to convert an incoming stream event to a generic Map.
AWS Function Routing
One of the core features of Spring Cloud Function is routing. This capability allows you to have one special Java method to delegate to other internal methods. You have already seen this in action when the generic FunctionInvoker automatically routed the requests to your uppercase function in the Spring Cloud Functions on AWS Lambda.
If you implement multiple Java methods in the same Spring Cloud Function project you either deploy two separate Lambda functions with static routing information or you provide a dynamic routing method that decides which method to call during runtime. Deploying two separate AWS Lambda functions makes sense if you have different scaling, configuration or permission requirements per function. A single Lambda function is a valid approach when multiple Java methods share the same permission set or provide a cohesive business functionality.
Routing for multiple Lambdas
If you have decided to deploy your single Spring Cloud Function project (JAR) to multiple Lambda functions you need to provide a hint on which specific method to call. If you have decided to deploy your single Spring Cloud Function project (JAR) to multiple Lambda functions you need to provide a hint on which specific method to call. You can use the environment variable spring_cloud_function_definition to define which function should be invoked by the Lambda.
Routing within a single Lambda function
decided to deploy your Spring Cloud Function project with multiple methods to a single Lambda function you need a more dynamic routing approach. Since application.properties and environment variables are defined at build or deployment time you can’t use them for a single function scenario. In this case you can leverage MessagingRoutingCallback or Message Headers. More details are available in the provided sample.