Time for another update to Lambdasync. 🎉
The major bump is due to switching over to using Lambda proxy integrations to tie your API endpoint to your Lambda function. This affects both incoming event params and the response format and will most likely break apps deployed with previous versions.
So what is actually new in this release?
Lambda proxy integrations
Proxy integrations are great! They are arguably how API Gateway and Lambda should have been integrated in the first place. It connects an API Gateway resource to a Lambda function and simply passes on relevant data about the request into the event object of your Lambda function, all of that without writing a single line of Velocity template code.
It also specifies a return format that includes body, statusCode and headers so that you can control the APIs output from your code, instead of through API Gateway settings and Velocity templates.
I can now change JSON APIs back to Lambda functions in the project's tagline.
"A tool to scaffold, deploy and update Lambda functions on AWS Lambda from the command line."
Because the output type is determined by your function's response instead of my API Gateway template.
Local devserver
Lambdasync started out because I wanted to simply convert my Lambda deploy scripts into a tool I could install globally through npm.
Since then the scope has grown a bit to making Lambda development easier in general, and being able to do common tasks without having to login to the AWS console or writing a bunch of custom code.
One thing I've found myself doing is copying over an express server to most of my Lambda projects, that would let me run the API locally. So I won't have to do that anymore, a new lambdasync devserver command has been added that starts up a server on port 3003 that you can call to test your API without deploying it.
The server expects your Lambda function to return a proxy integration compatible object as mentioned above, i.e. {statusCode: 200, headers: {}, body: "OK" }.
Express apps on Lambda
It's easy to find yourself missing Express when writing Lambda apps. Especially when writing routing logic and switches to handle different http methods in the requests.
Writing an express compatibility layer for Lambda functions has been on my list for a while.
Turns out I don't have to, AWS Labs has a project called aws-serverless-express that does the job. It doesn't cover everything Express can do, but it supports the routing and most common use cases.
Running an existing express app on Lambda will in many cases be as simple as bootstrapping it with:
'use strict';
const awsServerlessExpress = require('aws-serverless-express');
const app = require('./src/app'); // Existing express app
const server = awsServerlessExpress.createServer(app);
exports.handler = (event, context) => awsServerlessExpress.proxy(server, event, context);
This is so awesome that I added a scaffolding option for it:
lambdasync new project-name --express
Will scaffold a new express project (based on the aws-serverless-express examples), ready to be deployed to AWS Lambda.