Think holiday sales or launch events. Surprisingly this is harder to pull off then one might think. You have to set up some sort of cron that triggers some function that publishes some piece of content.
It can be tough to build! That’s why I’m building newclick.io, a tool to help you schedule promotional content on your website. We’re starting with something simple, announcement banners, but will soon branch out to different types of components.
In this article, I’ll briefly describe some of the things that went into developing the newclick.io Scheduling API.
The first step was to figure out if this was even possible. How are developers scheduling content today? CMS platforms like Shopify and Wordpress allow users to set publish dates for things like products and blog posts, so it’s definitely achievable, but certainly, they aren’t using something like a crontab, are they?
It’s 2020 we run things in the cloud these days so any type of server-side crontab would be out of the question. This included out of the box solutions such as the node-schedule and node-cron libraries. These wouldn’t work with how I wanted to architect my servers.
From the very beginning, I wanted to use the serverless framework and deploy to AWS Lambda. We didn’t want to think about spinning up EC2 instances and worrying about uptime and other server-related things.
I wanted to keep the development focused on code and less on infrastructure. I was also intrigued by the inherent costs savings you get with Lambda functions. You don’t pay for idle server time, which made sense for my fledgling startup.
“So how am I going to pull this off?”, I thought. Well, I can’t use a traditional server cron so I needed to look elsewhere. That’s when I found AWS CloudWatch.
So with my new tool in hand, I was ready to start writing some code. I started by figuring out how to use the AWS SDK to interface with CloudWatch.
First I needed to create a constant that would be available throughout our entire application. I started by defining and exporting a
I used the CloudWatchEvents constructor to define a constant. It takes an AWS access key, secret key and region for it’s parameters. You can pass those in using environment variables, good practice in case these end up changing later.
Now that we have our
service ready to go, we have access to the
function. This allows you to schedule an expression using a cron-like syntax. We also have access to the
function which allows you to define a target, in our case a Lambda function (more on this later). For each event that’s scheduled I created a new CloudWatch Rule that runs a Lambda function for a given date and time. The expression passed into the function looks a lot like your standard cron expression.
The last step is to attach our target. The target is the
returned back from our
call. This tells our CloudWatch event to only processes this ARN (Amazon Resource Names).
And there you have it! We have a scheduled task ready to rock🤘
In follow up article are go into how and why this wasn’t enough, and why I needed to “clean up” our rules after they executed. Stay tuned!