---
title: Options for adding a blog to a Rails application
teaser: 'TL;DR: roll your own.'
tags: rails,blog,web
author: Tute Costa
published_on: 2016-11-18
---

A client recently came back to us to build new features into the project we've
created together. One of the additions they needed was a blog, which I expected
to have ready in a morning. A Rails app! A blog! [Simple and easy].

[Simple and easy]: https://www.infoq.com/presentations/Simple-Made-Easy

Our client needed to publish evergreen, categorized articles. Their application
makes use of Clearance, [Clearance middleware], and plain-old-ruby-objects for
authentication and authorization. We are very happy with its current
architecture, test coverage, and code quality.

[Clearance middleware]: https://thoughtbot.com/blog/email-confirmation-with-clearance

We wanted:

- a blog system with image uploads, related articles, tags, etc.
- that uses the existing design and layouts
- with clean and readable code
- no more than a day of work adjusting the new code to our architecture (users,
  permissions, and styles)

We tried three different solutions and finally decided to roll our own. This is
what we learned from each option.

## Mount a blog engine into our application

Since the [blog-in-fifteen-minutes video] is around, the Rails ecosystem has
seen several open source blog and CMS solutions.

[blog-in-fifteen-minutes video]: https://www.youtube.com/watch?v=Gzj723LkRJY

Web app problems are commonly solved in gems with active open source communities
taking care of them. I checked various gems so that we could write and maintain
the least amount of code possible.

A first realization I had was that there is no obvious choice for adding a blog
to a Rails app.

- There are many projects that are now abandoned.
- There are developer-focused gems, with Markdown fields and no WYSIWYG editor,
  deploys on `git push`, rake tasks, image attachments through Amazon S3 and
  copy-pasting URLs, etc. Examples are Octopress and Toto.
- There are whole Content Management Systems that we don't need, with features
  like static pages, cluttered WYSIWYG editors, multilingual support, etc.
  Publify, Comfortable Mexican Sofa and RadiantCMS are examples of this.
  `monologue` is not as big, but still bigger than we needed.

[`lines-engine`] felt like a good fit, and I took it for a ride. At first, I
plugged in the engine with no modifications. I liked how it generated the code
instead of relying on hidden views and controllers that the gem exposes. That
way it would be simpler to customize.

[`lines-engine`]: https://github.com/opoloo/lines-engine

I wasn't happy with it having an authentication implementation which requires a
new database table (`lines_users`), which is different from its `lines_authors`
table. We could use our existing `users` table for both roles. It also brings in
a set of new gems into our dependency tree. I'd rather keep our codebases as
slim as possible, but the deal breaker was its dependency on Carrierwave, while
this app already has a successful paperclip installation, either of which is not
trivial to set up and test in different environments. (`simple_blog` presents
this same issue for us).

`lines-engine` is written following different coding standards and scores higher
in code complexity than the rest of this app. Merging foreign code into our
repository will make it harder to read and reason about, increasing the chance
of introducing bugs and vulnerabilities.

I decided to modify the code available in the gem and generated by it, but it
was too entangled with the features we didn't need, in a way that stripping out
its non-necessary features would have taken as much time for us as building
exactly the features we wanted.

Unhappy about this progress installing it in our codebase, we tried using
`lines-engine` as part of a new Rails application, separate from the main app.

## Mount a blog engine into a _new_ Rails application

To avoid adding new code, dependencies, and redundant database tables into our
application, we thought of creating a new [suspenders] application (our Rails
template). Our scripts would automate the creation of the Rails app and its
deployment to Heroku. A new canvas would allow us to fully embrace whatever
conventions the lines team has embedded into their software, without the need
for adjustments or configurations.

[suspenders]: https://github.com/thoughtbot/suspenders

The disadvantages we discussed were:

- We’d need to maintain two up-to-date and secure Rails deployments
- We’d need to copy over markup and styles from the original app
- Each app would need to be deployed independently
- `lines` didn't at the time work with Rails 5
- Extra Heroku cost (although negligible)

The advantages didn't outweigh the disadvantages, and we considered going with a
hosted solution: the well-known WordPress.

## [WordPress]

[WordPress]: https://wordpress.com/

WordPress has been an effective blogging platform for more than a decade, with
close to 37 million websites now hosted on WordPress.com, and thousands of
one-click install plugins to extend installations.

With hosted WordPress we wouldn't need to take care of the deployment process,
keep the software up to date and secure, or build and test any user interface.
At first I thought we wouldn't be able to easily reuse the markup and styles we
have in our main app, but [Brenda](https://twitter.com/brendamarienyc) (designer
on the team) had ported designs to WordPress before, so we signed up for an
account to test our assumptions.

While setting the website up we found out that hosted WordPress didn’t allow us
to freely edit the templates or theme as we need, and hosting a WordPress
project to edit the theme defeated the purpose of using WordPress in the first
place.

## Rolling our own

We decided to spike up our own. This was my first impulse as a web developer who
loves Rails, and I consciously postponed it because [less software] is better.
So, hello again Rails! Let's see how useful it is to "scaffold" Article and
Attachment models, and how productive it is to hook the new controllers to our
authorization logic.

[less software]: https://gettingreal.37signals.com/ch10_Less_Software.php

In about an hour I had an Article CRUD interface with paperclip attachments
working. I then found the [lepture Markdown editor], a good compromise between a
simple implementation and real-time feedback for the writer to understand how
will the article display in the browser. Our client already knows some HTML, and
could quickly ramp up on Markdown using this editor.

[lepture Markdown editor]: http://lab.lepture.com/editor/

Our Controllers and Policy objects allowed us to quickly build up the CRUD code,
hooking up authorization logic quickly and securely. Because all code looks
similar, it was easy for me to replicate the tests for authentication and
authorization.

We added some logic to show a featured blog post and a featured attachment per
post. By the end of the day we had a working blogging engine with as simple of
an implementation as we could, and useful for our client and his customers.

## Other alternatives

Colleagues pointed me to two other alternatives I didn't consider that day:

- Composing blog posts in WordPress, and have an RSS importer in the Rails
    application
- Using [Contentful] to build the blog without the need to build the UI

[Contentful]: https://www.contentful.com/

## Conclusion

Rails makes it so easy to spike up a good CRUD interface that for us it's easier
to build simpler features into existing applications, or generate a Rails
application with sane defaults through our [suspenders] template, than checking
what's state of the art in RubyGems for a known problem like a blog.

For anything more complex than this simple version of a blog, I’d argue in favor
of using an off-the-shelf solution. You might want to read [to gem or not to
gem], [Elle]’s blog post on when does it make sense to incorporate new
dependencies into your project.

[to gem or not to gem]: https://thoughtbot.com/blog/to-gem-or-not-to-gem
[Elle]: https://twitter.com/aemeredith