React JS and Rails – real-world results

There are many React JS intros out there, but too few articles about bringing React into an existing Rails app.

At Cook Smarts, we brought React JS into the core of our application, used by thousands of people each week. We moved quickly from the conceptual beauty of React to figuring out how to make it work 100% of the time.

Here’s what React JS delivered in just a bit of time:

  1. A bug-free user experience back to IE 7
  2. Speed, with no detectable latency on the client side
  3. Better structured JavaScript
  4. Thrilled users, who now have a more modern app experience
  5. Developer happiness (that’s me!)

First, some background. Cook Smarts is a service that helps people plan their weekly at-home meals. It suggests meals for the week, and the user can choose which ones to make, add meals from other weeks, adjust serving sizes, and adjust for dietary restrictions.

This is a lot of user interaction. A month ago, users selected which meals to make through a vanilla form. We then generated a static grocery list and meal plan. If they wanted to make any changes, they had to submit the form all over again.

Screen Shot 2014-12-29 at 6.30.05 PM

Screen Shot 2014-12-29 at 6.31.14 PM

It worked, but it needed improvement. Users wanted the app to remember their choices and allow them to check items off the grocery list. They wanted to make their selections as they browsed, not all at once.

We chose React JS because it is un-opinionated and friendly to existing apps. We could drop React into particular parts of the app without changing any other parts.

After implementing React, the meal planning experience is this simple, with no forms:


React is based on components that you arrange in a tree that basically documents itself. Here are the basic components for grocery list page:

  • GroceryListContainer
    • GroceryListItems
      • GroceryListItem

… and for the menu page:

  • DaysContainer
    • Day
      • DayTitle
      • DayVersion
      • DayServings

With React, you code each component separately, in a mix of JavaScript and HTML called JSX. Your component code contains the layout and behavior of that component, and React makes everything happen on the client.

React has minimal impact on your Rails app’s overall structure, making it easy to bring into an existing app. Here were the basic steps to implementing it:

  1. Add react-rails to your gemfile
  2. Create a directory in app/assets/javascript called “components” and create your components there as .JSX files
  3. Reference your new components in your views
  4. Create the server-side API’s necessary to feed and interact with your React components (this is not React-specific, just something an app needs to do as it implements more client-side functionality)

I presented to a local meetup about the process of implementing React for Cook Smarts, and hope to put together a how-to soon. In the mean time, check out these great resources for incorporating React and Rails:

Feel free to tweet me with any questions!

Update: See a full example of adding React to a Rails app

User announcements for Ruby on Rails with the Starburst gem

If you have an app with users, chances are you need to make announcements to them from time to time.

Starburst allows you to show messages to logged in users within your Rails app. Once the user closes the message, they won’t see it again.

You can target messages to particular groups of users, based on their database attributes or your own methods on the User class. For instance, you might send a message only to users on your premium plan.

Starburst remembers on the server who has closed which message. Therefore, a user who closes a message on their desktop won’t see it again on their mobile device. Starburst doesn’t use cookies, so a user won’t see an announcement they’ve already read if they switch devices or clear their cookies.

Starburst is in production on Cook Smarts, where it has served announcements to thousands of users.

Find out how to install and use Starburst on its GitHub repo, and post an issue there with any feedback!

11 Essential Services for Rails Apps

Developing an app is never a solo effort, even if you are the only developer in a company. We live an ecosystem of services and open source tools that make development more rapid than ever before.

This article covers services and tools that are critical to most modern web applications.

1. Error handling

You need to be aware of any exceptions that occur in your app in production, as they generally indicate bugs.


Recommended. After you take five minutes to set up Honeybadger, it will alert you to any errors on your app, and allow you to easily browse through each time that error happened. Information with the error will generally tell you who was logged in at the time, so you can provide proactive support to your users.


Airbrake may be the dominant error reporting service, as it just acquired its competitor Exceptional. From my experience, Setup is not as simple as Honeybadger’s, and the interface is so minimal that browsing through the history of an error can be cumbersome.

2. Commerce

Stripe and Braintree offer customers a seamless purchase experience in your app, allowing you to sell one-off items and subscriptions. Both are customizable enough to be transparent to the customer, providing you with full control over the user experience.


Recommended. Stripe is extremely developer-friendly on its own, so can be used in quite a custom manner in your Rails app. Unless you use a Stripe partner, you will be writing custom code to interface with Stripe. Stripe Checkout can shave off time off front-end development.


Recommended. Unlike Stripe, Braintree offers PayPal integration and phone support. It has matched Stripe’s features including user interface elements that you can plug right in to your app. As of October 2014, Braintree is offering no transaction fees on your first $50,000 of transactions, which could save you around $1,500. Braintree has made Stripe less of a default choice than it was before. Be sure to compare both.

3. E-mail – transactional

Transactional e-mail is specific to a customer. It may include an invoice, an alert about the customer’s account, a summary of the customer’s recent activity, etc. Generally, the contents of a transactional e-mail is different for every customer.


Recommended. From the creators of MailChimp comes an extremely powerful service with generous pricing. Just plug in Mandrill’s SMTP information into Rails ActionMailer, or use Mandrill’s API to send a ton of messages at once. Mandrill offers robust logging, allowing you to see the full contents of recently sent messages. Its deliverability stats demonstrate MailChimp/Mandrill’s excellent record in getting e-mails to people. It is reliable and fast, churning through thousands of messages in just a few minutes (from my experience). Finally, it is free under a certain message limit, and very reasonable thereafter, particularly for MailChimp customers. Many apps will spend just a few bucks a month on Mandrill, if that.

Having transitioned a web app from Sendgrid to Mandrill, it is difficult for me to recommend anything other than Mandrill. Do check out SendGrid and Mailgun, though.

4. E-mail – mailing list

You may want to send all of your users, or particular subsets of them, updates on your service, promotions, and other marketing e-mails.


Recommended. MailChimp has strong libraries for Ruby and other languages lets you add, manipulate, and remove users from your lists easily. You can send custom information about your users, such as which plan they are on, to MailChimp, for targeting purposes.

Customer automation tools

Many apps have needs beyond simple mailing lists. You may want to segment customers based on their behaviors – for instance, reminding a customer to take a certain action if they haven’t already. Check out MailChimp’s newly revamped automation features.

If you need more advanced customer segmentation, check out AWeber and Infusionsoft. Other specialized offerings, like Drip, address niches like e-mail-based courses. With these three tools, be prepared to pay more for a small list than you would with MailChimp.

5. Storage

Generally, you should store static assets, such as your logo, in a separate location from your app. Certainly, you should store any user-submitted images in a separate location.

Amazon S3 + Carrierwave

Recommended. Amazon S3 provides a place to store static assets, such as images and attachments. In the simplest use case, you would manually upload images like your logo, and reference those from your views.

In a more advanced use case, you could allow users to attach images to items in the app, and dynamically upload those images to S3. For that, check out Carrierwave, which makes file uploads to S3 amazingly easy.  Also check out the Paperclip gem.

6. Database


Recommended. PostgreSQL is a relational database that enjoys wide adoption among hosting providers like Heroku and EngineYard, and recently introduced highly optimized JSON fields that support more free-form data. It’s a well-maintained, reliable, fast database that should do the trick for most production apps.  Check out how to get started.  If you’re on a Mac dev environment, use to set up a local Postgres server on dev.


MongoDB is a non-relational database suited to more fluid information like documents and “mashups” of data from multiple sources. Some use MongoDB to bring in data from relational database and present it in a different way, since it is so flexible.

Beware, though, that without the rules of a relational database, a MongoDB database is harder to govern, and bulk changes a bear. Consider Mongo if you feel the data you are storing would not be appropriate for a relational database, but be sure to check out Postgres’ new JSON features first.

7. Performance monitoring

New Relic

Recommended. New Relic tells you which methods in your app are running slowly. In many cases, it’s free to use, and you can always upgrade for more granular information. It will alert you to sudden slowness in your app, which is important as you scale. There’s no reason not to get started with a free account for a production app.

App Signal

App Signal, based on Europe, integrates error reporting and performance monitoring in a very clean interface. It’s worth checking out.

8. Code quality

Static analysis checks out your code to find antipatterns, or poor practices could make your app less efficient or more difficult to maintain.

Code Climate

Code Climate quickly finds the poorly-formed or inefficient Ruby and JavaScript code in your app, so you know what to refactor first. Then, it monitors your GitHub repo so you don’t regress.


Prefer to do it yourself rather than use a hosted service? Code Climate likely uses RuboCop for much of its analysis, and you can run it locally for free.

Ruby Science

This isn’t a service, rather a book, but it’s excellent reading that can help you address some of the issues brought up by Code Climate or RuboCop.

9. Authentication

Authentication these days still includes user names and passwords, but is quickly expanding to social sign-in through networks like Google, Facebook, Twitter, and GitHub.

Devise (+ optional Omniauth)

Recommended. The long-time gold standard for authentication in Rails app, Devise pulls its weight as a solution that is quick to implement but also very extendable. It supports user name and password authentication out of the box, and has built-in support for Omniauth to support social sign-in without much pain.


Clearance is for people who either, 1.) want very simple user name and password authentication and don’t envision going beyond that, or 2.) want to further control and customize the authentication in their app. Most importantly, it is easier to understand what Clearance is doing because it’s code is lighter. Without turnkey integration with Omniauth, Clearance makes it harder to integration social sign-in.

10. Hosting


Recommended. EngineYard’s support is exceptional, with e-mail and phone available no matter what plan you’re on. You know exactly what you’re getting, because your app and database are hosted on fully-fledged virtual machines with clear specs. You can deploy, manage backups, and spin up/down servers through a simple web interface, never touching the command line.


Heroku is conceptually interesting and powers a lot of Rails app. It uses an original concept called “dynos” to allocate your app’s resources and allow you to scale. This abstraction could be helpful, but many might prefer to work with the actual VM’s that EngineYard offers. You’ll most certainly be dealing with the command line, but Heroku’s tools are good.

I’m hesitant about Heroku’s support. You can’t pick up your phone and call them, like you can with EngineYard. Heroku’s default support plan has a “1+ day” response time,  while EngineYard offers a 30 minute response time around the clock for urgent issues. Both services offer enhanced support plans, but EngineYard’s built-in support appears to be better.

11. Backup

If you use a platform-as-a-service provider like Heroku or EngineYard, you’ll generally get backup in the package. Just be sure to use it!

There’s more I haven’t covered here, like continuous integration and deployment. It goes to show that 1500 words don’t do justice to the vast ecosystem available to developers.