There are several projects connecting the last mile between the AWS API Gateway and AWS Lambda. In the summer of 2016, the only available integration was a one-to-one mapping of an API Gateway Resource and a Lambda Function. There were ways to make it a somewhat efficient developer work flow. However, it produced annoying friction.
Last November 2016, AWS introduced the 'Proxy' interface. This interface allows the API Gateway to proxy several resource endpoints to a single Lambda function. However, this mostly just pushed the issue down the road. This is because you need to now have an efficient way to distribute the requests to your code within that single Lambda Function.
One such interesting project aiming to reduce that friction is the AWS Serverless Container. It attempts to seamlessly connect your Lambda Proxy entry point to your code. It has interfaces for Spring, Jersey and Spark. It and other projects like it pass the Lambda Proxy request to a servlet/dispatcher front controller.
However, when I tried to do anything real or bring in other Spring projects, the constraints often got in the way and soon became counter productive. Also, it seemed like these projects were trying to enforce the wrong concern. AWS Lambda feels much more event-driven and has a distinct message passing scheme. Rather than a request-response MVC front controller.
So in this project, I tried to solve the issue by implementing message routing via Spring Integration. Additionally, you can run your code locally via Spring Boot.
A key to make Spring Boot play nice with Lambda is to tell it not to run a full web environment:
publicServerlessOutputhandleRequest(ServerlessInputserverlessInput, Contextcontext) {
if(!initialized) {
applicationContext = newSpringApplicationBuilder(LambdaConfig.class)
.web(false) //tells Spring not to setup a servlet and listen on port
.run(newString[]{});
initialized = true;
}After wrapping the Lambda request body in a Spring Integration Message envelope, then one option to route is to set a header. You can use whatever scheme makes sense for you.
Message<String> message = MessageBuilder.withPayload(serverlessInput.getBody())
.setHeader("route", (serverlessInput.getHttpMethod()
+ serverlessInput.getPath().replace('/', '-'))
.build();Four key parts of Spring Integration are needed:
- Messaging Gateway
@MessagingGatewaypublicinterfaceControllerGateway {
@Gateway(requestChannel="requestChannel")
publicMessage<?> route(Message<String> message);
}- Integration Flow to, typically, route to a deserializer
@BeanpublicIntegrationFlowrequestFlow(){
returnIntegrationFlows.from("requestChannel")
.route(newHeaderValueRouter("route"))
.get();
}- Integration Flow to route to a Controller or Resource
@BeanpublicIntegrationFlowgreeIntegrationFlow(){
returnIntegrationFlows.from("POST-greeting")
.transform(Transformers.fromJson(GreetingMessage.class))
.channel("POST-greeting-activator")
.get();
}- Service Activator triggering your logic
publicclassGreetingController {
@RequestMapping(method = RequestMethod.POST, produces="application/json")
@ServiceActivator(inputChannel="POST-greeting-activator")
publicGreetingMessagereply(@RequestBodyGreetingMessagegreeting) {
greeting.setMessage("Well...hello there");
returngreeting;
}
}This is a simple happy path and you are likely to need more complicated (and potentially automatic) routing schemes. But Spring Integration provides the building blocks.
Areas for improvement:
- Cold startup time with Spring (way too slow, but probably tunable)
- Need a seamless way to automatically recognize resource de-serialization
mvn clean packageTo run locally:
mvn spring-boot:runcurl -d "{ \"message\":\"hi\" }" -H "Content-Type:application/json" -X POST http://localhost:8080/greeting