Streaming Twitter Bot in Node

Over the years I've played a lot with Twitter and different bots and interactions. Shoot, there are write-ups on this blog about authenticating raw Twitter requests with OAuth, extending that to handling Twitter streams with Guzzle, and then doing it again with raw streaming requests. Using these tools and learnings I've created a few little bots, some handling realtime interactions and others more basic, all of which are using PHP. Maybe it's time to look into another language.

First, a disclaimer. When I set out to build this latest bot I really wanted to use ReactPHP. This event-driven framework is pretty darn awesome and seems to be perfect for handling a streaming API. However, it only handles HTTP/1.0, doesn't do chunked-transfer, has no OAuth baked into the http-client, and is very much beta. I didn't feel like diving that deep, not again, so instead went with Node. And there's an awesome client already built in Node that made building a bot stupid easy.

Twit is a Twitter API client written in Node that handles both REST and streaming endpoints. It seems to be fairly mature, having been around for four years. After installing it with npm, setting up a basic bot is simple as pulling in twit and instantiating with your credentials.

var twit = require('twit');
var bot = new twit({
  consumer_key: 'CONSUMER KEY',
  consumer_secret: 'CONSUMER SECRET',
  access_token: 'ACCESS TOKEN',
  access_token_secret: 'ACCESS TOKEN SECRET'
});

Now, with this bot I wanted to automatically respond to some tweets with a website. I'm not entirely sure if the recipients should be constrained to only followers of the bot or if there should be any filtering to avoid spammy behavior, but for a proof of concept I have it listening to an open stream. Basically, any time someone tweets that they deserve a cookie, the bot will send yougetacookie.com at them. If they say someone else deserves a cookie, then someone else gets sent the link.

Aside: yougetacookie.com is a little project I built some four or five years ago as a joke. It drops a cookie on your browser, with values like 'chocolate chip' or 'M&M', and then on refresh it will scold you for trying to 'consume' too many cookies and ruining your dinner. Mild internet humor.

Anyways, Twit has some syntactic sugar when it comes to dealing with streaming endpoints. Streaming Twitter endpoints have a few special messages that are mixed in with the normal tweets, like limit notices and warnings, that are triggered as events by the client. This makes it very easy break up the code or chain things along without worrying about writing the logic to detect anomalies in the stream.

bot
  .stream('statuses/filter', {
    language: 'en',
    track: [
      'should have cookie',
      'deserve cookie'
    ]
  })
  .on('connect', function (request) {
    console.log('Connecting...');
  })
  .on('connected', function (response) {
    console.log('Connected!');
  })
  .on('limit', function (message) {
    console.log('Limit notification received');
    console.log(message);
  });

This chunk of code opens up a streaming endpoint and spits out some debugging information along the way. The endpoint itself, 'statuses/filter', is a basic search endpoint for all public tweets. Technically the 'track' field is a comma-separated parameter in the request, but Twit will convert the array for you.

Several of the events respond with contextual data in the callback. The 'connect' event will return the outgoing request to Twitter, and the 'connected' with the response information from the connection. Both of these can be very useful for debugging. I decided not to fill out my logs too much in the early stages of the bot, though later on I may add in some response codes and authentication errors in case things start acting weird.

Once the base is built out it's time to actually handle the incoming tweets. These are just different events coming in, so all we need to do is listen for them and pass them onto a callback.

bot
  ...
  .on('tweet', function (tweet) {
    console.log('Tweet received: ' + tweet.text);
    if (tweet.retweeted) {
      console.log('Is retweet - ignoring');
      return;
    }
    if (
      tweet.text.match(/REGEX/i) &&
      tweet.in_reply_to_screen_name
    ) {
      console.log('Sending tweet to mentioned user');
      bot.push('statuses/update', {
        status: 'TWEET HERE',
        in_reply_to_status_id: tweet.id
      }, function (error, data, response) {
        // add in logging here
      });
      return;
    }
    if (
      tweet.text.match(/REGEX/i) &&
      !tweet.in_reply_to_screen_name
    ) {
      console.log('Sending tweet to original author');
      bot.post('statuses/update', {
        status: 'TWEET HERE',
        in_reply_to_status_id: tweet.id
      }, function (error, data, response) {
        // add in logging here
      });
      return;
    }
    console.log('Unmatched tweet, ignoring');
  });

Regex matching is a necessary evil. Twitter search endpoints perform basic queries and will return a lot of collateral. There is no exact phrase matching or anything, so for this bot I needed to double check that the responses received deserve action. Plus, as defined earlier, this bot will either send a message to the author or a mentioned user, so I needed to figure out if the author deserved the cookie or if the author thinks someone else deserves one.

Once beyond the boring matching is something more fun, the actual update itself. I'm able to reuse the bot object inside through the magic of javascript scope and just have it issue a simple update. Now, I've tried this before with some of my streaming PHP bots and was never able to get it to work. I'm not sure how Twit handles things differently - in PHP I had to instantiate two separate clients with two separate sets of credentials.

And that's it. 81 lines of liberally spaced javascript and a streaming bot that issues two different types of responses is born. As much as I like the PHPs this was pretty easy. I may end up writing future bots with node if the upkeep of this little one is simple enough.