Building a Social Media Marketing App (Part I)

I work for a marketing firm, where social media marketing is a big part of my coworker’s lives. They spend a large amount of time creating content, getting it approved, scheduling it and analyzing its performance.

This list is an oversimplification, it doesn’t touch on graphic design, the strategies that go into the type and timing of social posts, engagement monitoring and the 8 million other little pieces involved to create a successful social media marketing strategy. While social media seems like a simple thing, there is actually a lot going on behind the scenes.

My company uses several different applications and software to accomplish this piece of the marketing pie: Word, Canva, Dropbox, Basecamp, email and the social media platforms themselves (Facebook, Instagram and Twitter, mostly). Our social media managers create content in Word and Canva, store it in Dropbox, assign it to be approved internally in Basecamp, email it for any external (read: client) approvals and then schedule or post directly in the platforms themselves. We’ve used various web apps for scheduling in the past, but they’re quickly abandoned because they don’t fit well into the flow, don’t work well or are too complicated.

Executing a social media strategy in this way works, but it’s a pain and that drives me nuts. What if we could write, approve, schedule and monitor social media posts in one place? That would save time, reduce headaches, and honestly just really cool. Enter Liz building a social media marketing application.

This idea combines some of my favorite things about programming: integration, APIs, simplifying tedious processes, solving problems and helping people.

The Tech Pieces

The plan is to use PostgreSQL, Rails and React. To make sure I’m continuing to grow and learn, I’ll attempt to use SCSS instead of my usual vanilla CSS/Flexbox combination.

At the minimum, I’ll integrate the Facebook API for scheduling, posting and analytics. Ideally, I’ll also incorporate email notifications as well as integrate Basecamp, Twitter and Google Docs APIs. Stretch goals will involve Canva and Dropbox integration.

User Stories

• As a user, I can connect any Facebook page or profile that I have edit permissions for, to the application
• As a user, I can create new posts with text, links and images.
• As a basic user I can edit and delete my own posts.
• As an editor user, I can edit and delete my own posts and the posts of other basic or editor users.
• As an admin user, I can edit and delete any posts.
• As a user, I can associate my created posts with a client or personal Facebook account.
• As a user, I can assign my created posts to be reviewed by an editor or admin user.
• As an editor or admin user, I can approve posts of other users.
• As a user, I can schedule my posts to be posted on Facebook.
• As a user, I can see a dashboard with my assignments, latest posts and latest post performance.

Getting Started

$ rails new social_marketing_assistant -T --database=postgresql
$ cd social_marketing_assistant
$ git init
$ git add .
$ git commit -m "Initial commit."

First I created a new Rails app with the rails new command, passing the -T flag to tell Rails to skip the default testing files, since I’ll be using RSpec. Adding the database option tells Rails to use PostgreSQL instead of the default SQLite3 database.

Then I initialized a local git repository in my new app’s directory, added and committed all the initial files.

Next I created a new repo in GitHub and set it as the remote upstream branch for my local repo.

$ git remote add origin https://github.com/LizLaffitte/social-marketing-assitant
$ git branch -M main 
$ git push -u origin main 

According to the Git docs, the -M flag in my second command $ git branch -M main, renames the local branch to main. In an effort to be more inclusive, GitHub now uses main as the default initial branch name. You can configure Git to use main as the initial branch name as well: $ git config --global init.defaultBranch main

The last command, $ git push -u origin, adds an “upstream (tracking) reference, used by argument-less git-pull and other commands.” (Git Docs) Basically, it allows you to run $ git pull or $ git push without specifying a remote branch.

echo 'gem "rspec-rails", group: [:development, :test]' >> Gemfile
bundle install
rails generate rspec:install

Next I installed the rspec-rails gem, specifying that it was for the development and test environments, and ran bundle install. The last command in this group sets up RSpec with the basic, default configurations.

At this point, I realized I had forgotten to specify a webpack option when creating my Rails app, so I ran bundle exec rails webpacker:install:react.

$ rails g model user username:string

This is where my errors began. The generator command hung for an hour as I wandered off to do other things. Running $ spring stop and then the generator command again worked for me.

At this point, I wanted to run the default tests that were created by the generator. Enter error No. 2!

$ rspec
Failure/Error: ActiveRecord::Migration.maintain_test_schema!

PG::ConnectionBad:
  could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?

Rake commands gave me a similar error. What resolved this error for me, was specifying a host in my database.yml file: host: 127.0.0.1.

Then I got lovely errors indicating that I didn’t include a password, and then that my password was incorrect. After muddling the waters with a few different attempts to resolve the issue, I realized I had PostgreSQL installed for both Windows and WSL.

I uninstalled both instances, reinstalled for Windows, and supplied the username and password I set up in my fresh install to database.yml. I used the dotenv-rails gem to take advantage of environmental variables, and avoid pushing my username/password combo up to GitHub.

Note that the syntax is a little funky because of its placement in the database.yml file:

development:
  <<: *default
  database: social_marketing_assistant_development
  host: 127.0.0.1
  username: <%= ENV['PG_USERNAME'] %>
  password: <%= ENV['PG_PW'] %>

With all that work done, and barely an actual line of code written, I finished setting up the building blocks for my social media marketing application. Next stop, database planning!