Here’s a rundown of the main protagonists;

The Lambda

The star of the show. Parses the request for the form parameters (sent over as a JSON object), does some basic verification to supplement the client-side handlers and invokes SES to email the form details back to our underground lair. Code available from the usual Github.

But what the dickens are AWS lambdas?

Lambdas are functions that run directly on the AWS infrastructure without the need for you to set up your own EC2 VM or S3 storage. You only pay for them while they’re running (the first million invocations are free, after that it’s $0.02/million requests o_O) which makes them very cheap to own for small modules of functionality.

You can write Lambdas in JavaScript (Node.js), Python or Java 8. You write a function, bind it some kind of event source(e.g. an event coming from one of the other Amazon services, an change to a file in an S3 bucket or something going on in a log file). The source in our case is restful API exposed on the API gateway. More on this in a mo’

This is the meat & potatoes of the Lambda code

exports.handler = function(event, context) {

var emailDetails = {

“name”: event.name,

“email”: event.email,

“company”: event.company,

“subject”: event.subject,

“message”: event.message

};

sendEmail(emailDetails, context)

};

event contains the JSON object that was sent over HTTP POST, and we use context to let the caller (and logging) know whether this invocation was a success or not.

The rest of the code is here, but the whole thing is only 50 lines long, and over 10% of that is whitespace and logging.

And that is essentially all you need to create. This function just lives in magic cloud land (i.e. on someone else’s computer) and responds to your invocations on demand. No need to have any compute or storage permanently available.

SES (Simple Email Service)

Configured to send emails on my behalf. I needed to prove that I owned the domain that I’d be using to send the emails by performing some DNS shenanigans on my naming provider, but it was pretty straightforward.

More here if you need it)

The API Gateway

This is where you expose your Lambda to the outside world.

I wanted form to POST a JSON object to the Lambda, so I set up a new Resource and configured a handler with two methods; POST and OPTIONS.

The POST method is the one I needed for my app, but because my site was running at a different domain to this API, I needed to enable CORS, and the OPTIONS method is required for that.

AWS has a pretty nice overview and test interface for your API

After configuring the POST method and binding it to my Lambda, I needed to configure some kind of security, and opted for using an API key (which is sent by my form) and restricting CORS to use my website domain as origin.

I tested/debugged for a while using the console (shown above), and then once it was all working used Postman to do the real external testing.

And that, dear readers is it! It took me longer to write the article than to get the form handler up and running, and it’s ubercheap.

Also, I can now wang ‘AWS Lambda’ on my CV :)

Now for a cuppa tea!