How I Made a Twitterbot with Node.js

The other day, I decided to make a Twitterbot to help streamline my marketing efforts for my art brand. I wanted to make a bot that would retweet tweets from a different user, selected from a list of users. I wanted the bot to also run once a day.

For my project, I used the following:

  • Node.js
  • twit – Twitter API client for Node.js
  • Heroku – platform for deployed applications

Creating an Application with Twitter

To get started, I used the Twitter application form to register my application. The process is pretty straight forward, and once it was completed, I was able to grab the necessary consumer_key, consumer_secret, access_token, and access_token_secret.

Building the Bot

To get started with Node.js, I created a new project directory. Then I ran npm init.

I ran the following commands to ensure I had the right packages to build the application:

npm install --save dotenv http twit

Next, I created the environment variables. I created a .env file in the directory, where I added in my project keys:

CONSUMER_KEY="add_it_here"
CONSUMER_SECRET="add_it_here"
ACCESS_TOKEN="add_it_here"
ACCESS_TOKEN_SECRET="add_it_here"

In my index.js file, I connected the .env variables to the application:

require("dotenv").config();
const config = {
  consumer_key: process.env.CONSUMER_KEY,
  consumer_secret: process.env.CONSUMER_SECRET,
  access_token: process.env.ACCESS_TOKEN,
  access_token_secret: process.env.ACCESS_TOKEN_SECRET
};

Then I added logic so the bot would retweet tweets from a list of users or retweet tweets tied to specific hashtags. First I set variables to use twit and to control the number of retweets the bot would make when the code was executed:

const twit = require("twit");
const Twitter = new twit(config);
const MAX_RT_COUNT = 1;

I found the Twitter ids for several users that I wanted to the bot to retweet. I used their ids instead of their screen names, in case a user decided to change their screen name. In order to keep track of who was who, I stored details about each user in a comment:

const USERS = [
  "15057943", // moma
  "14803372", // saam
  "5225991", // tate
  "22009731", // design museum
  "81783051", // artsy
  "17896874", // itsnicethat
  "158865339", // fastcodesign
  "21661279", // creative review
  "16336998", // print magazine
  "17623957", // design observer
  "418597196", // creativebloq
  "15446126", // design milk
  "18201801", // interior design
  "19038849" // how design
];

I made a function that would filter through the list of users, so that each day of the week, a different user would get a retweet from the bot:

const getUserOfTheDay = () => {
  let date = new Date();
  let dayOfMonth = date.getDate();
  let pickUserIndex = dayOfMonth % USERS.length;
  return USERS[pickUserIndex];
};

Next, I created the logic for retweeting tweets tied to different hashtags. I ultimately decided not to deploy this functionality, but I wanted to keep it around in case it’s useful in the future:

let retweetTags = async function() {
  try {
    const { data } = await Twitter.get("search/tweets", {
      q: "#art, #painting",
      result_type: "mixed",
      lang: "en"
    });

    const statuses = data.statuses.slice(0, MAX_RT_COUNT);
    // loop through the first n returned tweets
    for (const status of statuses) {
      // the post action
      const response = await Twitter.post("statuses/retweet/:id", {
        id: status.id_str
      });
      if (response) {
        console.log("Successfully retweeted");
      }
    }
  } catch (err) {
    // catch all log if the search/retweet could not be executed
    console.error("Err:", err);
  }
};

// retweetTags();

Lastly, I added the code for retweeting tweets from my list of users:

let retweetUsers = async function() {
  try {
    const { data } = await Twitter.get("users/show", {
      user_id: getUserOfTheDay()
    });

    const status = data.status;
    // make sure tweet isn't in reply to another user
    if (status.in_reply_to_status_id == null) {
      const response = await Twitter.post("statuses/retweet/:id", {
        id: status.id_str
      });
      if (response) {
        console.log("Successfully retweeted");
      }
    }
  } catch (err) {
    // catch all log if the search/retweet could not be executed
    console.error("Err:", err);
  }
};

To run the bot locally, I added retweetUsers(); to the file, then ran node index.js in the terminal.

Deploying the App to Heroku

Once I had my app up and running locally, I wanted to deploy it somewhere so it could run automatically. I did this by deploying it to Heroku.

I added a Procfile to the project, and added the line worker: node index.js to the file. Then I created a new Heroku project by running heroku create twitterbot-retweet. Next, I had to define the environment variables in Heroku by running heroku set:config key_name="key_value" in the terminal.

By accessing the Heroku dashboard online, I had to toggle on the worker for the bot (it was located under the “Dyno formation” section).

After deploying the bot, I realized I wanted the bot to run once every day, so I looked into options for how I could wake the application up once a day in order to execute the code. I ended up going with the simple setInterval method.

If your curious about how all the code looks, or want to see an up-to-date version of the project, you can find it on GitHub.

How to Make Requests to Yelp’s API v3 (Fusion)

I recently worked on updating an app I made a couple of years ago, that was using Yelp’s API. I was running into some issues deploying the older version of the app to Heroku, so I decided to update the API it was using to the latest version for Yelp, v3.

As I’m writing this, I found that the Yelp API documentation was a little confusing. The older API required a consumer key, consumer secret, token, and token secret. The Yelp Fusion API only requires an Authorization parameter.

Authentication for the Yelp API is outlined here, although I had to do a bit of fiddling around until I was able to successfully make an API GET request. Here’s what Postman looked like once I was able to make a successful call (click the image to see a larger view):

Something I wasn’t aware of from the APIs I’ve worked with, is that the Headers required a Content-Type with the value application/json and an Authorization with a value that started with the word Bearer, a space, and then the API key I had received from Yelp. So the value looked something like Bearer 203498lksjsdlkfej9if

If you’re curious about how I wrote the code for my application, you can take a look at my github repo for the app, What am I Even Doing?

A Brief Overview of Node.js and Express.js

If you’ve worked with JavaScript frameworks and libraries, chances are that you’ve heard of Node.js and Express.js. So for those who are unfamiliar to these terms – what exactly are they?

Node.js

Node.js is an open-source JavaScript runtime environment, that uses Google’s V8 JavaScript engine, where you can build server applications. Node.js is not a framework, although it has many modules that are written in JavaScript. It has event-driven architecture that is capable of asynchronous I/O, otherwise none as a form of input/output processing that allows other processing to continue before the transfer of data has finished.

Express.js

Express.js is a web application framework for Node.js, that’s used for building APIs. It is also known for being a backend component of the MEAN stack.

I’ve worked with Node.js and Express.js to create APIs, so I feel like I can never think about one of them without having the other one come to mind.

WDI Day Forty-Eight: Web Sockets and Lab Time

Web sockets are a way that users can interact in real time with each other on websites. During class we did a quick tutorial where we created a chatroom – it was some pretty cool stuff. After walking through the chatroom with socket.io, we tried to add Angular to the mix, and yet again it tripped me up a bit.

In the afternoon the instructors announced the web socket lab, where we will have to build a game with the MEAN stack and use web sockets. I can’t believe how many labs we’ve had – here I thought this weekend I would be able to get a head start on my final project. Looks like I’ll be refactoring the lab that was due this morning and have to complete yet another project.

I still feel pretty shaky with Angular JS, so I’m going to attempt to do several tutorials over the weekend. I did manage to put a basic MEAN stack framework in place for my lab project that I’ll work on customizing more tomorrow. I am also going to attempt to create Tic Tac Toe.

WDI Day Forty-Seven: MEAN Lab

The MEAN stack is pretty difficult to work with – at least it is for someone who is completely new to it. I enjoy working with Mongo DB, Node.js, and Express.js. The problem child in the stack is Angular – I’m realizing I’m not grasping everything that I thought I was.

Today was the last day to work on our MEAN stack lab. I decided to create an app where users can post their projects and have other users critique their projects. Users can upvote/downvote projects as well as critiques.

I was able to successfully complete the following:

  • Have users create new projects, delete existing projects, and view all projects
  • Have users upvote/downvote projects
  • Have users add critiques for different projects
  • Have users view all critiques made on projects
  • Have users upvote/downvote critiques
  • Seed the database with dummy data
  • Use show/hide Angular directives to make a better user experience

At this time, I have yet to do the following:

  • Allow users to update posts
  • Add the ability to delete comments
  • Create RegEx to prevent users from submitting critiques if the critique uses banned words or phrases
  • Polished styling (I was only able to do some preliminary styling)
  • Launch the app to Heroku

Although building this application was a huge struggle, I felt as though the application functioned a lot better than my project 3. It was also quite a learning experience!

WDI Day Forty-Six: Building a MEAN App & Starting a MEAN Lab

We had an introduction to adding Angular to the mix when building apps with Mongo DB, Express JS, and Node JS. However, the intro was a little too brief for everyone’s liking. Essentially we walked through an exercise that incorporated Angular with the rest of the stack, but not many of us were feeling at all confident with this new component.

After attempting to complete the in-class assignment, we were introduced to our lab for the week – building a MEAN stack application. We could either work in groups or alone. Although I enjoy working with others, when I’m struggling to retain new information, I do much better being able to struggle and absorb things on my own a little bit before returning to the group. Thus I opted for working on my own project.

It was a bit of a struggle – I tried to walk through the in-class assignment several times, but was unable to build something that could function. Next I started Googling all sorts of tutorials, desperate to find a working example of a way to format and use all these different pieces together. Luckily, I finally stumbled upon something that worked and helped me add basic CRUD functionality to the app. Once I had the working pieces in place, I pretty much called it a day. I was pretty sleep deprived from the day before, but I did indeed successfully complete a large chunk for the lab.

I’m hoping that tomorrow goes well and that I can successfully refine this application. I have a sturdy foundation now–all I want to do now is add to it and read over a few documents to make sure I’m understanding everything involved with the basics for the MEAN stack.