Day 03 - Preferences [Rails 5]


  • Application: Complete and tested with two endpoints
  • CI: Complete
  • Deployment:
    • Dev: Complete
    • Production: complete


Today we decided to change it up by creating our API using Rails 5. Most of our services are written in Rails 4, so this was a good chance to see how our libraries handled the update. Our project topic was user preferences flags, which amazingly, gets accessed often and on each page view. Building this out should be beneficial to our front end services and the move to SOA. Our awesome senior engineer, Jake Sparling, paired with me for a ride through our custom CLI library. Jake has recently worked through an API for our user's saved content so he brings his experiences to the party. The coding was extremely quick, and leveraging rails' generators sped us along very quickly. Typically we've used activemodelserialzers but since Rails 5 has jbuilder included in the Gemfile, we decided to use it. It was super easy to use and intuitive from only a few examples. I recommend giving it a try since it's less abstract than AMS.

Learnings of the day:

API design

User preferences are strange. The term user preferences in a developer's mind immediately brings visions of join tables.

Why would you make an endpoint for a join table?

Well looking over all our use cases we decided it was best to have a resource that is a user_preference. This would hold a reference to a user, the preference, as well as a flag to tell if that preferences was on or off.
That last flag was the deciding factor to use user_preferences as our endpoint. Perhaps user_preference_flag would be better, but if that changed to contain more information than a flag, then we're reducing understanding.

Has anyone else had similar endpoint architecture discussions? What did you do?

Updates needed to our CLI

While ruby is super slick with its generators,

rails g scaffold Preference name:string

we still ran into a few hurdles around manual script building and configurations. Some of these included: 1. Adding common files to .gitignore 2. Auto generate docker build and publish scripts 3. Pregenerate database.yml to include environment variables. 4. Include dotenv to our Gemfiles for quick use in development 5. Handle new database creation.

All great things to increase our development velocity.

Successful deployment


Jake and I worked closely with Aaron Devey in Infrastructure to see how the new configuration management tool worked. It was amazing that only after a few minutes of work with our pre-deploy scripts we had the application running in our Test, Staging and Production. Another step towards full dockerized infrastructure.

I'd like to thank the Infrastructure team for working hard to get the custom configuration manager working.

Stay tuned for our next API!