These days, there are so many different choices when it comes to serving data from an API. In many cases, you just want to bring something to market as fast as you can. For those times, I still reach for Ruby on Rails.
When building an API in Rails, you need a good solution for structuring your JSON. ActiveModel::Serializers (AMS) is a sensible choice. It's powerful alternative to jbuilder, rabl, and other Ruby templating solutions. It's easy to get started with, but when you want to serve data that quite doesn't match up with the way ActiveRecord (AR) structures things, it can be hard to figure out how to get it to do what you want.
In this post, we'll take a look at how to extend AMS to serve up custom data in the context of a Rails-based chat app.
Everyone knows more is better. More kittens, more money, more apps. Why settle for one Ruby project, when you can have three? We'll take one Rails app for authorization and one to serve an API. Hey, let's throw in a Sinatra proxy server serving up an AngularJS app to while we're at it! Now we're cookin'!
With the announcement of Rails 4.2 came some exciting news: Rails now has built in support for executing jobs in the background with Active Job. The ability to schedule newsletters, follow-up emails, and database housekeeping tasks is vital to almost any production application. In the past, developers had to hand-roll this functionality using gems like Resque Scheduler or Sidekiq Scheduler. With the release of 4.2, setting up jobs for workers to execute at a later time is built in to Rails, making developers' lives easier. In this article, we'll take a look at how to set up Active Job to send a follow up email to a new user in a sample Rails application.
We've heard it again and again, like a nagging schoolmaster: keep your
Rails controllers skinny. Yeah, yeah, we know. But easier said than
done, sometimes. We know we should push it down to the model layer, but what if we want simple models? What about dealing with external APIs?
Time to get custom!
Modeling large, complex domains "the Rails way” can cause some serious pain. Ruby and Rails are supposed to make developers happy. Let's not allow “the Rails way” and complex domains to take the “happy" out of ruby development.