Serverless github bot with AWS Lambda and API Gateway

This tutorial will show you how to build a small github bot app which is "listening" for pull requests' events on "open" and "reopen" by greenkeeper.io. When the author is the greenkeeper bot, our bot will in turn, correct the title and the tags of the pull request to match conventions.

If you've come to this article because you already have knowledge about the technical topics, but you are more interested in the concrete steps, you can skip the following introductory parts and go directly to the technical specifics below. To go to the technical details scroll down to the "10 steps to make it happen" section ;)

The script will actually be pretty small and simple, though there are quite some interesting ideas you might get on the way.

Serverless

Serverless computing is a relatively new trend which is getting greater popularity after Amazon released their AWS Lambda service in the end of 2014. I published about this topic in a bit more details earlier this year. In one sentence, serverless architectures (aka cloud functions) are getting traction in cases where high-level architecture control is sufficient for developers who delegate the details about the infrastructure management to a hidden underlying layer managed by a cloud provider.

In addition to the low maintenance efforts, pricing per resource is also a lucrative opportunity for app developers - at the moment 1 million requests to AWS Lambda are free - this is generous! Later, pricing continues to be calculated based on actual usage. This means that applications cost money when they actually compute. That's good for both up-scaling and down-scaling.

Here's a graphic from acloud.guru which explains this evolution step in simple terms, I think:

Lastly, cloud functions such as AWS Lambda come well into play in event-oriented designs. Here's a simplified list of some official use cases:

event-driven services where the cloud function is run in response to other events - usually triggered by AWS S3, SNS, DynamoDB, etc.

A github bot app can be considered as a service from the second set of scenarios. The end result is an API endpoint responding to POST requests (events) from github webhooks.

Notes on the AWS serverless stack

Watching videos and reading tutorials on the topic can get you pretty excited. Here are some notes about steps which didn't go totally smooth during my journey, i.e. I want to prepare you for the reality before you get frustrated ;)

1) The AWS services ain't that easy, especially if you're relatively new to AWS in overall

2) We speak cloud abstraction here - it is not easily reproducible for local development

I spent quite some time researching on ways to have the whole AWS API Gateway + AWS Lambda setup locally so that I can start hacking quickly on my computer, but I haven't found anything so far. If you have one or some in mind - please tell me!

3) We still write JavaScript and Node.js - be ready for the regular hurdles you'll normally have

The fact that you're delegating the infrastructure complexity to someone else out there doesn't mean that your code will automagically work, at least not in the Node.js world, not at the moment.

For example, sometimes you would receive errors like this and you will have to apply your JavaScript knowledge and patience to switch between versions of Node, transpile the code for the Lambda to be able to show you useful error messages ...

For me, the serverless framework worked pretty well in the deployment part. It definitely hid most of the complexity of understanding template languages and setting up boilerplate code for the function to work.

Try to keep the scope of permissions to a minimum to ensure best security in your applications. Both AWS and serverless provide other authentication options you might feel more comfortable with.

Notes on the github part

The setup on github is simpler than AWS. Basically, you'll need to read about webhooks. The documentation is without a doubt - great - it walks you through all the stages from setting up a local dev environment, testing a hook, and also having a good knowledge of the structure of the webhooks' payloads.