Yep, this blog post is the result of yet another great discovery by yours truly! After making a few AWS Lambda services that automate Twitter activity I realized that I needed to deploy the same function many times, each as a scheduled event in AWS but with slightly different configurations (such as twitter access keys for the desired account, keywords for posts to like, etc). I wanted to keep the same core codebase of logic for each type of lambda function but somehow deploy multiple versions of it, and I wanted to be able to upload the code in one place and have all the places where it's used be updated without having to deploy to each one individually. Here's how I managed to do it!
When A Config File Doesn't Cut It
Being the emphatic little Clojurian that I am, I used the cljs-lambda leiningen template to scaffold out my aws lambda function which right out of the box creates a separate little "config" file for you to put constants, configuration data, and other things you might need to come in and tweak later. Of course this separation of concerns is not unique to clojure, and in fact this generalization of lambdas that I'm about to explain can be used in aws lambda functions written in javascript, python, java, or whatever else the aws platform decides to support. A config file is all well and good for a single aws lambda function that's meant to live as one thing, but what about when old Matty Scott wants you to deploy the same lambda function but with a slightly different config file containing his twitter credentials? Do you make a whole new git repo and duplicate the entire codebase? Surely once this grows to a few people it would turn into a nightmare to update something across all those projects, and juggling multiple config files in a single project doesn't sound fun either. What I really needed to do was completely rip the config file out of the source code and instead pass that data in as arguments to the lambda function. Welp, that's exactly what I did, and it turns out that even for scheduled events (think AWS cron jobs) you can pass parameters into your function when invoking it. Let's take a closer look at that.
AWS Lambda Functions As Scheduled Events With Input Parameters
If you haven't already, sign up for an aws account an log into your console. I'm assuming you already have a lambda function up there in aws and want to create some scheduled jobs to run it at some predefined times. As an example let's take my cljs twitter unfollower example and create one version for Jim and one version for Louie. Now, you might be tempted to try to add the the cloudwatch event right from the lambda section of AWS, but watch out because for some reason currently the cloudwatch event triggers rule creator does not give you the option to pass input params into the lambda function.
Instead, go to Services in the menu bar at the top of the page and choose CloudWatch. Then under Events click on Rules. This will bring you to a page where you can enter the exact cron expression you want (under Event Source on the left-hand side) and then under Targets -> Configure input you can enter some JSON text, and HUZZAHH, you've put in some input parameters!! Finding this hidden little buried away hidden gem of an input field was the eureka moment for me that I realized that this was where I could put the config data instead of packaging it in with the source code for the lambda function.
After entering this information you can add a name and description for this aws "rule" that encompasses all the cron scheduling and input parameters.
Once you have one or more cloudwatch scheduled events linked to your AWS Lambda function you can see them back in the Lambda section of AWS when you click on your function and then the box labeled "Cloudwatch Events".
Key Takaways
The main thing to take away here is that in order to make it easy for your scheduled events to be leveraged by multiple clients or customers you should make one single, generic codebase that expects input parameters and then you create and AWS Rule for each client or customer. This gives you total control over the frequency of execution and configuration parameters. It's a simple tip, but I hope you take this mighty power and do something awesome with it!
RSS Feed