Welcome back! In order to build the basic backend of our forum app, we need to generate the basic models and set up their associations. We will be using polymorphic associations to increase the flexibility of some of our associations, making our code much more reusable.

TL;DR: Generate the base models we will use in our database: User, Topic, Reply, Like. The Reply and Like models have polymorphic associations to allow them to be added to either a topic or a reply. The whole code is available here.

Models

The base unit of any forum is the topic. Each topic centers around one particular question. Other users can write answers to the question and comment on other users’ replies.

Right away, it is clear that we will have at least three basic models: User, Topic, and Reply. Users can have many topics and each topic can have many replies. For this example, each reply to a topic can have many replies itself.

Let’s add a little bit more complexity: likes. Users can like topics or comments that they find particularly useful or interesting.

As it currently stands, we now have four models, users, topics, replies, and likes. User is a base object which has many topics and many replies, which we are going to call comments for the sake of clarity. Topics can have many replies and many likes. They must also have a title and contents. Replies have content, can have many likes, and belong to a user and to a topic or reply.

Generating the New Rails App

Prerequisites

Before generating a new rails app, we need to make sure that PostgreSQL is installed. On Mac or Linux you can install it with Homebrew like so:

brew install postgresql

On Mac, you can start postgres with the following command:

brew services start postgresql

Unfortunately, Homebrew does not support homebrew services on linux, so you will not be able to start PostgreSQL on linux with the above command. Instead, you will have to create a systemd service. See this link for my implementation of a PostgreSQL systemd service.

Building the Backend

Navigate to the directory where the new app will live and run the following command:

rails new miniforum --api -d  postgresql --skip-bundle

This will create a new slimmed down rails application using PostgreSQL as its database engine. Skip bundle install for the moment because we will update the Gemfile immediately and will need to run bundle install anyway.

Once the command has completed, navigate into the new app directory, open the Gemfile and add the following lines:

# Uncomment the line with BCrypt
gem 'bcrypt'
gem 'jwt'
gem 'dotenv-rails'
gem 'graphql'

Now that we’ve specified our additional dependencies, go ahead and run bundle install.
Once bundler has finished installing the dependencies, we will need to install the GraphQL gem into our application. Run the following command to do that:

rails g graphql:install

We’re not going to use GraphQL just yet, but installing it now will mean that we'll be ready to develop with it later.

We’ll start by generating the User model:

rails g model User email username name password_digest

We’re leaving all of these attributes as strings by default as BCrypt requires password digests to be stored as strings. BCrypt requires the password field in the database to be called password_digest in order to use the has_secure_password macro.

Next, we’ll generate the Topic model:

rails g model Topic title content:text user:belongs_to

In the topic, we want the content to be a text type as the text type is designed to hold longer data than a plain string.

Next, generate the Reply model:

rails g model Reply content:text user:references post:references{polymorphic}

Since a reply can belong either to a topic or to another reply, we want to make sure that we set up a polymorphic relationship. Essentially, polymorphic associations allow the same association to refer to more than one different kind of model. In our case, since there are two models that reply can belong to (Topic or Reply), we need a polymorphic association to represent this behavior. I highly recommend this article for more details about polymorphic associations.

When building a polymorphic association, the name of the field should be an abstraction that represents all of the different kinds of models that will be associated. In our case, we’re calling the field that represents a topic/reply association “post” since both topics and replies are kinds of posts.

Finally, generate the Like model with the following command:

rails g model Like user:references post:references{polymorphic}

Again, like the Reply model, likes can belong to either a topic or a reply, so we’re setting up the same kind of polymorphic association that we set up above.

Now that we’ve generated all our models, we need to create our database and get migrate our models:

rake db:create
rake db:migrate

I use rake db:migrate instead of rails db:migrate simply because using rake cuts out a little bit of the code that rails has to run to figure out what task to complete. Rake gets straight to the task, and as a result should run a little bit faster.

Adding associations and validations

In order to get our associations set up properly, we still have some work to do.

User Model

Add the following code to the User model:

# app/models/user.rb
class User < ApplicationRecord
    has_secure_password
    has_many :topics
    has_many :comments, class_name: "Reply"
    has_many :likes

    validates :email, :name, :username, :password, presence: true
    validates :username, :email, uniqueness: true
    validates :username, format: {with: /\w/, message: "only alphanumeric characters allowed"}
    validates :email, format: {with: /[\w\.\+]+@\w+(?:\.\w+)+/, message: "must be a valid email address"}
end

Note in line two, the has_many :comments this is a reference to the comments that the user has made on other posts. The class_name: “Reply” argument tells Active Record that the class to find the comments attribute is actually the Reply class

The validations ensure that each user has an email, name, username, and password. Usernames and emails must be unique. The third validation line uses a regular expression to validate that the username is alphanumeric. Finally, the last line uses a regular expression to validate that the email address roughly follows the format of hello@world.com.

If you need help with regular expressions, check out this regex tester and this excellent article on JavaScript regular expressions (which mostly carry over to Ruby regular expressions).

Topic Model

Next add the following code to the Topic model:

# app/models/topic.rb
class Topic < ApplicationRecord
    belongs_to :user
    has_many :replies, as: :post
    has_many :likes, as: :post

    validates :title, :content, :user, presence: true
end

Notice the has_many :replies, as: :post and has_many :likes, as: :post. These lines set up the associations between topics and and replies. Active Record knows to look in the replies table for the ID of the topic to find all the associated objects, but since the association is polymorphic, Active Record will not be able to find the correct :topic_id field in the table.

The as: :post argument tells Active Record to look in the replies table, but to look for the field :post_id instead of a :topic_id field. Setting up the model in this way means that we’ll be able to access a topic’s list of replies and likes in the normal way.

Reply Model

For the Reply model, we’ll need to do something similar:

# app/models/reply.rb
class Reply < ApplicationRecord
    belongs_to :user
    belongs_to :post, polymorphic: true
    has_many :replies, as: :post

    validates :content, :user, :post, presence: true
end

Note that here, in addition to the polymorphic “replies” field, we also have the line belongs_to :post, polymorphic: true line. This tells Active Record that the post field in the database should be polymorphic. Without the polymorphic: true argument, Active Record would try to find a table named “posts” and would raise an error because we didn’t define such a table.

Like Model

Finally, for the Like model, all we need to add is this:

# app/models/like.rb
class Like < ApplicationRecord
    belongs_to :user
    belongs_to :post, polymorphic: true

    validates :user, :post, presence: true
end

Again, we have the polymorphic: true argument, but otherwise this is the simplest model in our database.

Everything is good to go for this post. I hope you that it was instructive for getting the basics of the backend setup. Polymorphic associations can be difficult to understand at first, but they add a whole lot more power to database associations.

The whole code for this part of the series can be found here.