We love open source and we invest in continuous learning. We give back our knowledge to the community.

How to Build a Rails 5 API Only and Ember Application

Comments

A few days ago, following long discussions, Rails API was merged into Rails master branch.

Because of that, in our latest post we discussed how to build an API only application. We’ve also shown how to integrate it with a client-side application implemented using Backbone. If you’ve missed this post, check it out and learn more about how to integrate Rails API with an Backbone application.

In this post, we are going to show how a very similar client-side Ember application can be integrated with the same backend application implemented using Rails API. Like in our previous post, we are going to use the TodoMVC application.

In addition, we are going to comment about some issues that were fixed in Rails and Active Model Serializers in order to make the integration easier. These improvements were the result of testing Rails API with an Ember application, as part of our efforts to make it work properly with some of the most popular JavaScript frameworks.

Building the Backend

Generate the Rails API only application

First of all, we need to generate a new Rails API only application from scratch. Rails 5 is not released yet, so we have to clone the Github repository and generate our application directly from the source code.

git clone git://github.com/rails/rails.git
cd rails
bundle exec railties/exe/rails new /tmp/my_api_app --api --edge

In case you want a detailed explanation about the list of directories and files generated by this command, please take a look at our previous post.

However, if we compare with what was described in our previous blog post, we can see a subtle difference in the generated Gemfile: the active-model-serializer gem version changed from 0.10.0.rc1 a 0.10.0.rc2.

The new Active Model Serializer release candidate includes a new adapter that works properly with the Ember’s RESTAdapter. This addition simplified a lot the integration of our Rails API only backend and the Ember client-side application.

Scaffolding the Todo resource

The Todo items in the Ember application have two attributes: a string title and a boolean isCompleted. The following step to build our backend application is precisely to add a resource representing these Todo items.

We can do it just running the rails generate scaffold command:

bin/rails g scaffold todo title isCompleted:boolean

Since we’re now using a new version of the active-model-serializer gem, specifically the version 0.10.0.rc2, the scaffold command generates the serializer file for this resource. At the time of writing our previous post, we had to run another command to generate the serializer. It is now changed to be automatically run along the scaffold generator. In fact, this was an enhancement implemented only a few days ago.

Don’t forget to run bin/rake db:migrate to update the database schema.

Choose the appropriate JSON serialization format

Our Rails API only application is going to respond incoming requests in a given JSON format. The process to convert the data into this format is called serialization and this will be possible in our backend application thanks to Active Model Serializer adapters.

By default, Active Model Serializer uses a format provided by the flatten_json adapter which is a very simple format that only includes the list of attributes without any additional metadata about the data being serialized. For instance, using this adapter, a Todo item would be serialized like:

{
  "id": 1,
  "title": "Todo 1",
  "isCompleted": false
}

Luckily, we have some adapters shipped with Active Model Serializer in 0.10.0.rc2, giving us a lot of flexibility. In particular, we need to pick a JSON format matching our Ember application. We can achieve that by selecting a format that works well with the Ember’s RESTAdapter. The main requirement specified by the RESTAdapter is the presence of the root object’s key as part of the JSON payload, as it is explained in the Ember RESTAdapter documentation. It means we want to serialize a Todo item like this:

{
  "todo": {
    "id": 1,
    "title": "Todo 1",
    "isCompleted": false
  }
}

This is easy to do with Active Model Serializer if we choose the json adapter instead of the flatten_json. We can configure it by creating a new initializer file config/initializers/ams_json_adapter.rb including the following line:

ActiveModel::Serializer.config.adapter = :json

At this point, the backend application should be ready, so it’s testing time! Start the web server with bin/rails s and let’s create our first Todo using curl:

curl -H "Content-Type:application/json; charset=utf-8" -d '{"todo": {"title":"Todo 1","isCompleted":false}}' http://localhost:3000/todos

The API application should return the created item serialized in JSON format, including the root element:

{"todo": {"id":1,"title":"Todo 1","isCompleted":false}}

Now, let’s get the Todo items list:

curl http://localhost:3000/todos

and the response should look like this (note the root element in plural):

{"todos": [{"id":1,"title":"Todo 1","isCompleted":false}]}

Integrating with the Ember client-side application

We want to have both components working together, integrating our Rails API only application with the Todo list frontend application implemented with Ember.

The original implementation from TodoMVC is our starting point, but we must do a few changes to have it working properly with our backend. In fact, the TodoMVC Ember example uses the browser local storage to persist Todo items, but we want to have our Rails API application doing this job.

After downloading the Ember application code from TodoMVC, we need to have a newer version of the ember-data library to integrate properly this frontend application with Rails API. If you’re interested on reading more about this, we’ve opened a pull request on the TodoMVC repository. So whilst the pull request is not merged or ember-data updated in other way, we need to update this library by hand using curl:

curl http://builds.emberjs.com/release/ember-data.js > node_modules/ember-data/ember-data.js

We have now all the vendored JavaScript code updated, so we are prepared to connect the frontend with our Rails backend. We configure that by changing the Ember adapter from LSAdapter (local storage) to RESTAdapter. You can learn more about Ember adapters in the Ember documentation page.

Let’s replace the following piece of code in the js/app.js file:

1
2
3
  Todos.ApplicationAdapter = DS.LSAdapter.extend({
    namespace: 'todos-emberjs'
  });

with the RESTAdapter’s definition pointing to our backend:

1
2
3
  Todos.ApplicationAdapter = DS.RESTAdapter.extend({
    host: 'http://localhost:3000'
  });

Finally, we have to configure CORS in the Rails API only backend because both applications will run in different domains (we will test the backend in localhost:3000 and the client-side application in localhost:9000).

In brief, we need to uncomment the rack-cors gem reference in the Gemfile, run bundle install and finally put the following code in the config/initializers/cors.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Avoid CORS issues when API is called from the frontend app
# Handle Cross-Origin Resource Sharing (CORS) in order to accept cross-origin AJAX requests

# Read more: https://github.com/cyu/rack-cors

 Rails.application.config.middleware.insert_before 0, "Rack::Cors" do
   allow do
     origins 'localhost:9000'

     resource '*',
       headers: :any,
       methods: [:get, :post, :put, :patch, :delete, :options, :head]
   end
 end

You can read more about how to setup CORS in our previous post.

We are now ready to test the whole application! Run the backend server with:

bin/rails s

and start a simple web server to test the Ember application:

ruby -run -e httpd . -p 9000

You can already try it out and start adding your first Todo items, just browse to localhost:9000.

Closing Thoughts

I hope this example illustrates another possible use of the new Rails API functionality that will be included in Rails 5.

We’re aware there’s still room to improve the experience. If you have the chance to try it out, we invite you to comment about your experience with Rails API.

We’d love to hear your feedback!

Resources

You can find the backend and frontend applications that we built in this article in Github:

The Ember application was borrowed from the TodoMVC project.

If you’re looking for a more modern & idiomatic implementation of the Ember TodoMVC check out this one. A piece of advice: the code in master doesn’t fully work when it’s integrated with our backend. There is an issue where Todo items are not completed in the Rails API only application when clicking on checkboxes. As far we tested, this open pull request fixes the problem.

How to Build a Rails 5 API Only and Backbone Application

Comments

A few weeks ago, an announcement was made referring to the imminent inclusion of Rails API into Rails core. Until now, Rails API has been a separated project and people have been using it through the rails-api gem.

Santiago Pastorino and I have been working on bringing Rails API into Rails for a while. After some further discussion, bug fixes and last-minute changes, the corresponding pull request was finally merged. We’re happy to confirm that all Rails API capabilities will be available once Rails 5 is released!

Rails API goal is to facilitate the implementation of API only Rails projects, where only a subset of Rails features are available. A Rails API application counts with lightweight controllers, a reduced middleware stack and customized generators. All these features were conceived looking for a better experience at the moment of building an API only application.

For more detailed information about the Rails API project, you can take a look at this Santiago Pastorino’s article about the project.

How to implement a Rails API backend for a simple Backbone application.

Let’s create an API only application! The rest of this article is a step-by-step example of how to build a Rails API backend for a simple TODO list application implemented with Backbone.

Since we want to focus on the backend implementation and its integration with the client side application, we decided to borrow the Backbone TODO application from the TodoMVC project.

Generating the Rails API only application

Once Rails 5 is released, creating an API only application will be accomplished by running:

rails new <application-name> --api

However, this feature was just incorporated into the master branch at the time of writing, so we need to generate the application directly from the most recent version of the Rails source code. The easiest way to have a copy of this code is by cloning the Rails Github project in our computer:

git clone git://github.com/rails/rails.git

Now we must run the rails new command in the folder where the repo was cloned. In order to have our generated project pointing to our local copy of the Rails source code, we need to run this command in the following manner:

bundle exec railties/exe/rails new <parent-folder-path>/my_api_app --api --edge

It’s a good idea to specify a path for the generated project, so we avoid creating the Rails API application inside the Rails source code folder. That explains the <parent-folder-path> placeholder in the example below.

Now, we can explore what was generated in the new project’s folder. You will notice that almost everything looks exactly the same than a regular Rails application, and that’s certainly true. However, let’s highlight what is different.

There are some changes in the generated Gemfile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
source 'https://rubygems.org'

gem 'rails', github: "rails/rails"
gem 'sprockets-rails', github: "rails/sprockets-rails"
gem 'arel', github: "rails/arel"

# Use sqlite3 as the database for Active Record
gem 'sqlite3'
# Use ActiveModel has_secure_password
# gem 'bcrypt', '~> 3.1.7'

# Use Unicorn as the app server
# gem 'unicorn'

# Use Capistrano for deployment
# gem 'capistrano-rails', group: :development

# Use ActiveModelSerializers to serialize JSON responses
gem 'active_model_serializers', '~> 0.10.0.rc1'

# Use Rack CORS for handling Cross-Origin Resource Sharing (CORS), making cross-origin AJAX possible
# gem 'rack-cors'

group :development, :test do
  # Call 'byebug' anywhere in the code to stop execution and get a debugger console
  gem 'byebug'
end

group :development, :test do
  ....
end

We can notice that stuff related with asset management and template rendering is not longer present (jquery-rails and turbolinks among others). In addition, the active_model_serializers is included by default because it will be responsible for serializing the JSON responses returned by our API application.

Let’s now check out the config/application.rb file:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
....
....

module TodoRailsApiBackend
  class Application < Rails::Application

    ....
    ....

    # Only loads a smaller set of middleware suitable for API only apps.
    # Middleware like session, flash, cookies can be added back manually.
    # Skip views, helpers and assets when generating a new resource.
    config.api_only = true
  end
end

The api_only config option makes posible to have our Rails application working excluding those middlewares and controller modules that are not needed in an API only application.

Last but not least, our main ApplicationController is defined slightly different:

1
2
class ApplicationController < ActionController::API
end

Please note that ApplicationController inherits from ActionController::API. Remember that Rails standard applications have their controllers inheriting from ActionController::Base instead.

In case you’re interested on turning an existent Rails application into an API only application, the differences mentioned below are the list of changes that you need to do manually in order to achieve that.

Scaffolding the Todo resource

The main purpose of our API application is to serve as a backend storage for our list of TODOs. For this reason, we need to generate a new resource in our Rails API project. After looking at the code of the Backbone TODO application, we know we will need to define a Todo model including some attributes: a string title, a boolean completed and an integer order.

Let’s use the scaffold command:

bin/rails g scaffold todo title completed:boolean order:integer

Again, we need to make sure all rails commands run the latest Rails source code in our computer, so we must run the executables from the bin folder (otherwise, the scaffold would use the rails code from an installed rails gem in the system).

This command is the same explained in the Rails’ guides and books about the framework. Rails API does not require any change or additional options in all subsequent commands. The rails-api option added to the config/application.rb is enough to alter how scaffolding and other things works in our API only project.

The generated TodoController looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
class TodosController < ApplicationController
  before_action :set_todo, only: [:show, :update, :destroy]

  # GET /todos
  def index
    @todos = Todo.all

    render json: @todos
  end

  # GET /todos/1
  def show
    render json: @todo
  end

  # POST /todos
  def create
    @todo = Todo.new(todo_params)

    if @todo.save
      render json: @todo, status: :created, location: @todo
    else
      render json: @todo.errors, status: :unprocessable_entity
    end
  end

  # PATCH/PUT /todos/1
  def update
    if @todo.update(todo_params)
      render json: @todo
    else
      render json: @todo.errors, status: :unprocessable_entity
    end
  end

  # DELETE /todos/1
  def destroy
    @todo.destroy
  end

  private
    # Use callbacks to share common setup or constraints between actions.
    def set_todo
      @todo = Todo.find(params[:id])
    end

    # Only allow a trusted parameter "white list" through.
    def todo_params
      params.require(:todo).permit(:title, :completed, :order)
    end
end

If we compare this controller with one generated for a regular Rails application, we would find some differences. First of all, the actions new and edit are not included. That’s because these actions are used to render the html pages containing the forms where users fill the data to be added or modified in the system. Of course, it does not make sense in an API because this application is not longer responsible for rendering html pages.

Looking at the render statements within the actions we can see more differences. The controller only responds in JSON format. The usage of respond_to, which allows us to handle different format responses or differentiate ajax requests, is not longer available.

The controller tests, generated by the scaffold in the file test/controllers/todos_controller_test.rb, are consistent with the actions and format of the responses expressed in the TodoController.

No template files are generated when scaffolding a new resource in our Rails API application. We don’t have the app/view folder in our project.

The config/routes.rb file includes now the following line:

1
resources :todos

This is exactly the same result after running the scaffold command in a regular Rails application. However, this line defines only the routes that are necessary in our API. In other words, new and edit routes are excluded now. We can confirm that by running bin/rake routes:

Prefix Verb   URI Pattern          Controller#Action
 todos GET    /todos(.:format)     todos#index
       POST   /todos(.:format)     todos#create
  todo GET    /todos/:id(.:format) todos#show
       PATCH  /todos/:id(.:format) todos#update
       PUT    /todos/:id(.:format) todos#update
       DELETE /todos/:id(.:format) todos#destroy

Do not forget to run bin/rake db:migrate, so the database is ready when the time comes to test our application.

Defining how TODO items should be serialized

Our API only application will respond incoming requests in JSON format, and here is where Active Model Serializers plays an important role. It requires to define the TodoSerializer class and provide the list of attributes from our Todo model to include in the responses.

Active Model Serializers offers a command to generate this serializer:

bin/rails g serializer todo title completed order

The result is the file app/serializers/todo_serializer.rb:

1
2
3
class TodoSerializer < ActiveModel::Serializer
  attributes :id, :title, :completed, :order
end

At this point, we have implemented with almost zero effort a working backend application. We can run bin/rails s to start the web server and test our API with the help of curl command.

Let’s create a new Todo

curl -H "Content-Type:application/json; charset=utf-8" -d '{"title":"something to do","order":1,"completed":false}' http://localhost:3000/todos

and it should return:

{"id":1,"title":"something to do","completed":false,"order":1}

Now, we can try to get the list of TODOs:

curl http://localhost:3000/todos

and the result should be:

[{"id":1,"title":"something todo","completed":false,"order":1}]

Putting both components to work together

It’s time to integrate the Backbone application with our backend implementation!

The original implementation of this TODO list application uses the browser local storage. However, we want to indicate that our Rails API application is the new storage for the data.

Let’s replace the following lines in js/collections/todos.js:

1
2
  // Save all of the todo items under the `"todos"` namespace.
  localStorage: new Backbone.LocalStorage('todos-backbone'),

with a definition for the URL of our API endpoint for TODO items:

1
2
  // Set the rails-api backend endpoint for this specific model
  url: 'http://localhost:3000/todos',

After this change, we are almost ready. Our last outstanding task is to configure the cross origin policy to make the communication between both components possible. This is necessary when the backend and the client components are in different domains. Since we are doing local testing, we will run both things in localhost but using different ports, so we will end up having CORS errors in the browser if we don’t configure any cross origin policy.

In Rails API, the handling of CORS is not enabled by default, however you can find the rack-cors gem listed in the Gemfile, but commented out.

In order to fix the CORS problem, we only need to uncomment this line and run bundle install again in the Rails API project. Also, we need to take a look at the file config/initializers/cors.rb. This file has an example of how CORS can be configured in our project.

Let’s do some changes in this file, so we can test both components, assuming that we will use port 9000 to run the client side application:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# Avoid CORS issues when API is called from the frontend app
# Handle Cross-Origin Resource Sharing (CORS) in order to accept cross-origin AJAX requests

# Read more: https://github.com/cyu/rack-cors

 Rails.application.config.middleware.insert_before 0, "Rack::Cors" do
   allow do
     origins 'localhost:9000'

     resource '*',
       headers: :any,
       methods: [:get, :post, :put, :patch, :delete, :options, :head]
   end
 end

You can read more about the rack-cors gem and how to configure the policies here.

Once we have configured the cross origin policy in our backend, we are ready to test our client side application. We should turn on the backend server (bin/rails s) but also run a separated web server for the Backbone application.

We can simply run a test server using Ruby to test locally the frontend. Run the following command in the Backbone application’s folder:

ruby -run -e httpd . -p 9000

Give it a try by browsing to localhost:9000. You will notice that TODO items are being stored by our Rails API backend now instead of the browser local storage. Therefore, both components are connected and communicated with each other.

Conclusion

The aim of this article was to show how easy is to implement an API only backend for a simple Backbone application using the new Rails API feature. Rails API just landed into Rails source code, however you can count with this feature because the next Rails major release is around the corner.

Some stuff can still be improved. For instance, the file containing the TodoSerializer class should be generated as part of the scaffold command when the active_model_serializers gem is included in the project. We have fixed this specific problem and it is already merged on master and ready for the next release of active_model_serializers.

We also have other options in terms of serialization. In fact, we have prepared Rails API to play well with JBuilder. This library is an alternative within the Rails ecosystem that allows to define JSON responses using templates instead of defining a serializer class as Active Model Serializers does.

Although Rails API is just being incorporated into Rails and further improvements can certainly be done, I hope you feel more confortable and productive implementing your APIs with this new functionality to be shipped in the next Rails version.

Enjoy exploring Rails API!

Resources

You can find the backend and frontend applications presented in this article in Github:

The Backbone application was based on the Backbone example included in the TodoMVC project.

Using the Page Object Pattern With Ember CLI

Comments

One of the most appealing features in Ember and Ember CLI is the ability to easily create functional or acceptance tests. But, the everyday interaction between UX and development, can hurt how these tests are maintained. Here, I try to describe an approach that helped us overcome this problem.

Let’s consider a simple example. Let’s assume we have a list of users and, we want to validate that a table with 2 users is rendered, so that we can later validate each user’s name.

1
2
3
4
5
6
7
8
9
10
11
12
13
<table>
  <caption>Users list</caption>
  <tbody>
    <tr>
      <td>Jane</td>
      <td>Doe</td>
    </tr>
    <tr>
      <td>John</td>
      <td>Doe</td>
    </tr>
  </tbody>
</table>

Ember, and more specifically ember-testing, provide a DSL that simplifies creation and validation of these conditions on our tests. An example of such an acceptance test in Ember would be:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import Ember from 'ember';
import { module, test } from 'qunit';
import startApp from '../helpers/start-app';

var application;

module('An Integration test', {
  beforeEach: function() {
    application = startApp();
  },
  afterEach: function() {
    Ember.run(application, 'destroy');
  }
});

test('List shows two users', function(assert) {
  assert.expect(4);
  visit('/users');
  andThen(function() {
    assert.equal(find('.users caption').text(), 'Users list');
    assert.equal(find('.users tr').length, 2, 'The list contains two users');
    assert.equal(find('.users tr:first .name').text(), 'Jane');
    assert.equal(find('.users tr:last .name').text(), 'John');
  });
});

As we can see in the above example, after visiting the /users route we validate that the data shown is what we expect.

The problem

While working on a client project, where we generate dozens of acceptance tests, we noticed that many of the CSS selectors used to look up elements were repeated across tests. In some cases, this repetition seemed like a smell.

Then, in some cases the complexity of selectors used prevented us to easily identify what we were trying to test. This can become very confusing, concealing the original purpose for the test. Take for example:

1
assert.equal(find('.users tr:nth-of-type(3) .name'), 'John Doe');

Another issue was how maintainable such tests became. For every change in the HTML, no matter how big or small, we’d probably need to update many tests to make these CSS selectors match.

The solution

Here’s where a widely-used design pattern came to the rescue: Page Objects. The main idea behind this pattern is to encapsulate the page structure being tested with an object, hiding the details of its HTML structure and therefore exposing the semantic structure of the page only.

In our case, the goal was to make the intention of the test clearer, hiding the fact that the users list is an HTML table. We also wanted to make our assertions as obvious and concise as possible, easier to read and understand.

Back to our example, this is a possible implementation for a Page Object:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
var usersPage = {
  visit: function() {
    return visit('/users');
  },
  caption: function() {
    return find('.users caption');
  },
  usersCount: function() {
    return find('.users tr').length;
  },
  firstUserName: function() {
    return find('.users tr:first .name').text();
  },
  secondUserName: function() {
    return find('.users tr:first .name').text();
  }
};

Now, we can take advantage of this object and write our acceptance test in an simpler manner:

1
2
3
4
5
6
7
8
9
10
test('List shows two users', function(assert) {
  assert.expect(4);
  usersPage.visit();
  andThen(function() {
    assert.equal(usersPage.caption(), 'List of users');
    assert.equal(usersPage.countUsers(), 'The list contains two users');
    assert.equal(usersPage.firstUserName(), 'Jane');
    assert.equal(usersPage.secondUserName(), 'John');
  });
});

As we can see, the intention of what we want to test is much clearer after applying the Page Objects pattern.

A step further

After applying this process to our application and introducing several objects, we started to notice a few additional patterns emerging. Our team decided then to extract those into auxiliary functions, which made the creation of Page Objects even easier.

We were then motivated to extract this into an Ember CLI add-on named ember-cli-page-object, which provides a small DSL for creating Page Objects in a declarative fashion.

If using the add-on, our previous example translates into:

1
2
3
4
5
6
7
var usersPage = PageObject.build({
  visit:          visitable('/users'),
  caption:        text('.users caption'),
  usersCount:     count('.users tr'),
  firstUserName:  text('.users tr:first .name'),
  secondUserName: text('.users tr:last .name')
});

A login page, for example, can be modeled like:

1
2
3
4
5
6
7
var login = PageObject.build({
  visit:        visitable('/login'),
  userName:     fillable('#username'),
  password:     fillable('#password'),
  submit:       clickable('#login'),
  errorMessage: text('.message')
});

This allows to express test intentions in a cleaner way:

1
2
3
4
5
6
7
8
9
10
11
test('Invalid log in', function(assert) {
  assert.expect(1);
  login
    .visit()
    .userName('user@example.com')
    .password('secret')
    .submit();
  andThen(function() {
    assert.equal(login.errorMessage(), 'Invalid credentials!');
  });
});

You can check out more examples and instructions on how to plug it into your own projects here.

For further information on the Page Object pattern, I recommend reading Martin Fowler’s original description here, as well as the definition on the Selenium’s wiki page here.

Getting involved

Try it out! We’re always looking for ways to improve the project. You can contribute by suggesting new features, fixing bugs, improving the documentation and working on the features from the wish list.

Rails API to Be Part of Rails 5

Comments

A decision was made to incorporate Rails API into Rails core 🎉 🎉 🎉. During the last week I’ve been working on this and, today we opened a pull request to discuss the results.

What is Rails API?

The original idea behind Rails API was to serve as a starting point for a version of Rails better suited for JS-heavy apps. The project consists of: Rails API per se, the Active Model Serializers project plus a bunch of ideas that haven’t been implemented yet. As of today, Rails API provides: trimmed down controllers and middleware stack together with a matching set of generators, all specifically tailored for API type applications.

For more detailed information about the Rails API project, please read my previous article on the subject.

Next steps: What we need to talk about?

We still need to discuss the “Rails way” for API applications, how API apps should be built and, what features we’d like included from our original list of ideas. In particular:

  • Do we want to avoid asset generation in Rails by having a back-end and a front-end apps?
  • Do we prefer to have a single application and keep asset generation in Rails instead?
  • Do we like Active Model Serializers better than Jbuilder?
  • If not, can we make Rails API play nicely with Jbuilder?

Join the conversation

Like every year, I’m attending RailsConf 2015 in Atlanta. This could be a great opportunity to meet and interact. So, please come find me throughout the conference or say hi if we run into each other. I’d love to talk about Rails API or any other topic. Comments, reviews, suggestions and improvements are always welcome.

ActiveModel::Serializers Rewrite (Upcoming 0.9.0.pre Version)

Comments

First of all, I want to apologize to all for the long time it has taken me to push this humble new code.

I started to work on ActiveModel::Serializers because I’m interested in the Rails API project in general and ActiveModel::Serializers in particular. Given that ActiveModel::Serializers has few contributors, I thought it could be a good opportunity to understand the code and help the community around the project.

Rails 4 Links Compilation

Comments

I’m leaving here a curated compilation of interesting links where you will find information that is not very well known. There are pull requests, issues, commits, examples, posts, videos and more about Rails 4.

Rails 4 in 30’

Comments

I gave a presentation in RubyConf Argentina about what’s new in Rails 4 (if you saw it please rate it). I’ve already posted the Rails 4 MindNode which I used to start to think about what I was going to present. The talk was in Spanish but I’m leaving here the English version of the slides.

Rails 4 in a MindNode

Comments

I’ll be talking at RubyConf Argentina, and the first thing I usually do when preparing talks is to think in a high level and then start going down form there. I find MindNode a great tool for that. So I started checking what was being added, removed and deprecated in Rails 4 (my memory isn’t good enough to have all that in the top of my head :P). The result is this MindNode I’m sharing with you …

Ruby Refinements Landed in Trunk

Comments

Refinements arrived to Ruby trunk here. The purpose of Refinements is to make monkey patching safer, extending core classes but limiting its effects to a particular area of code.

Rails for API Applications (Rails-api) Released

Comments

rails-api is a plugin developed by Yehuda Katz, José Valim, Carlos Antonio da Silva and me (Santiago Pastorino) which modifies Rails applications trimming down usually unneeded Rails functionalities for API applications. Do you remember we added support for this on core and it was reverted?. This plugin enables that again.