A DM-based database for twitterbots on AWS Lambda

Running a Twitter Bot on AWS Lambda is almost certainly free — the Twitter API rate limits are low enough that you’re likely not going to exceed the 3.2 million seconds of free compute time per month.

To make the @realBigBoyTrump TwitterBot, I needed to read each of Trump’s tweets and translate them to babyspeak:

Every two minutes, my bot polls Trump’s twitter account for any new tweets. How can we keep track of which tweets are new since our last check?

1. Bad idea: just check for tweets sent in the last two minutes
   This will miss tweets that were just over two minutes old (but that your last poll missed), and you’ll never get tweets back on any failed runs.
2. Good idea: use DynamoDB to store the last-seen tweet
   You just need to store one value here, so you’ll likely stay in the free tier
3. Best idea: use DMs as your database
   No fancy setup required, works just as well locally as on AWS, no credentials to share, and best of all, it’s as absurd as our president.

Here’s what our DM-based database looks like: just a DM to itself with the tweet ID of the last-seen tweet.

Benefits of this approach include:

1. Does the easy thing, not the right thing
   Uses the existing infrastructure for your TwitterBot
2. You don’t need to learn anything new
   No additional services needed, no additional setup needed
3. Slow and inefficient
   Rather than using hyperoptimized AWS database services or key/value stores, where you can override data and not increase storage costs, you instead have an infinitely growing list (until the president stops tweeting) and a Twitter API roundtrip to read a single value

All of these being traits that our Baby President embraces.