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?
- 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.
- 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
- 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:
- Does the easy thing, not the right thing
Uses the existing infrastructure for your TwitterBot
- You don’t need to learn anything new
No additional services needed, no additional setup needed
- 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.