5 tips para empezar con el pie derecho en Ruby on Rails

En este post os daré 5 tips que abarcan buenas prácticas, trucos, consejos, etc., que estoy seguro les servirán para empezar de la forma correcta en el mundo de Ruby on Rails.

1. Nested resources…

Con Ruby on Rails es muy fácil configurar nuestras rutas para anidar recursos, en donde, si bien no hay un límite para los niveles de anidación, se recomienda que este no pase de 1.

Esto se explica mejor con un ejemplo. Supongamos que tenemos la siguiente estructura:

# bad
resources :comunity do
  resources :users do
    resources :articles do
      resources :comments
    end
  end
end

El problema viene cuando quieres acceder a un artículo, y es que tú no deberías necesitar especificar el comunity_id o user_id. ¿O qué sucede si quieres una ruta para obtener la lista de todos los usuarios? ¿O de todos los artículos?…

Para ello se recomienda separar los recursos de la siguiente forma:

# good
resources :comunity do
  resources :users
end
 
resources :users do
  resources :articles
end
 
resources :articles do
  resources :comments
end

Sin embargo, esto no siempre se cumple, ya que también depende de la lógica de negocio que tenga el proyecto en el que trabajas. Por ejemplo, tenemos un recurso 'empleado', este pertenece y depende de otro llamado 'departamento' y este a su vez pertenece a un recurso 'empresa'.

resources :company do
  resources :departments do
    resources :employees
  end
end
 
resources :employees

Para este caso en específico sí es necesario tener las rutas de arriba, ya que un empleado pertenece a un departamento y un departamento a su vez pertenece obligatoriamente a una empresa. Incluso al final tenemos un recurso propio para administrar todos los empleados.

2. Usar o no usar scaffolding

Hay muchos puntos en contra sobre usar el rails g scaffold, esto porque te genera mucho código de más que normalmente no vas a necesitar, o porque no se generan las relaciones entre los modelos como se quiere, o porque simplemente algunos lo consideran como 'pecado'.

En la poca experiencia que tengo con Ruby on Rails, dentro de los proyectos reales nunca he usado scaffold, esto porque muchas veces un recurso no necesita una vista 'index' o una vista 'show', o porque los métodos de las acciones tendrán diferente lógica, etc.

Otra de las razones por las que no suelo usar scaffolding es porque trabajo bajo TDD y BDD, lo cual me lleva a tener que crear tests unitarios, funcionales y de alto nivel antes de empezar a 'codear' —el scaffold te crea todos estos tests por defecto, pero casi siempre estos no se adecúan a la lógica de negocio—.

Sin embargo, si usted quiere aprender Ruby on Rails o tiene muy poca experiencia, le recomiendo usar el scaffold, no para crear proyectos en producción, sino para analizar todas las características, métodos y código que este genera, específicamente para usarlos como guía, y así en un futuro usted pueda adaptar todo esto a lo que quiera.

Así también le recomiendo el scaffold para examinar los tipos de tests que este crea para los modelos, controladores y vistas para, de la misma forma, usarlos como guía.

3. TDD, make your tests first…

Tests unitarios para modelos, tests funcionales para los controladores, tests para las APIs, etc.

Si deseas tener toda tu aplicación sin bugs o errores desde el inicio, se recomienda trabajar con TDD —crear los tests primero, añadir la funcionalidad, correr los tests y finalmente refactorizar código—.

BDD también es más que recomendable; este usa los mismos fines de TDD con otro punto de vista: "testear lo que ves". Dentro están los tests de alto nivel o tests de aceptación.

Además, una de las cosas principales que las empresas de tecnología de hoy en día buscan en los ruby-developers es la experiencia trabajando bajo TDD o BDD, así que empezar desde el inicio con TDD no es mala idea.

Por último, ten en cuenta que aplicar TDD y BDD dentro de un proyecto hará que el tiempo de desarrollo se eleve, por lo que se deben tomar las medidas adecuadas para ello.

4. Rubocop y la Ruby Style Guide…

Si estás buscando alguna referencia sobre algún buen estilo de programación, entonces la Ruby Style Guide es para ti; esta es un conjunto de pautas y buenas prácticas enfocadas en Ruby y Rails que fue liberada para ayudar a los desarrolladores.

Rubocop, creada por el mismo autor de la Ruby Style Guide, es una gema que analizará todo nuestro código buscando posibles ofensas que tengas, dándote un listado exacto de ellas y sugiriéndote al mismo tiempo cómo puedes solucionarlas.

Rubocop es una gema más que recomendada, pues te obligará a escribir código de calidad, bien estructurado y, sobre todo, con buenas prácticas.

5. JBuilder vs Active Model Serializer vs to_json() vs RABL

Hay muchas controversias entre los métodos usados, sobre todo dentro de una API, para mostrar data en formato JSON. Entre estos métodos tenemos la propia función to_json(), JBuilder, RABL y Active Model Serializer (AMS).

En este caso hablaré solo un poco de cada una de ellas, tratando de dar ejemplos de dónde deberíamos usar cada uno de ellos, características, etc.

¿Cuál es más rápido?… AMS, esto porque no hace un render para las vistas desde el controlador (como sí lo hace JBuilder).

¿Cuándo usar JBuilder?… Si la estructura del JSON a mostrar difiere mucho de los atributos de tu modelo, entonces recomiendo usar JBuilder, esto porque dentro de sus plantillas puedes usar código Ruby, lo cual te otorga gran flexibilidad para aplicar los cambios junto a la lógica que necesitas.

¿RABL?… Funciona de forma similar a JBuilder, así que diría que es su competencia directa, pero su sintaxis confusa y con métodos de más hace que me aleje de ella. Prefiero JBuilder antes que RABL.

collection :@users
attributes :id, :name, :last_name, :article_id
child(:article) { attributes :title, :body }
node(:read) { |message| message.read_by?(@user) }

¿Y to_json()?… Si tan solo necesitas renderizar cosas específicas directamente desde el controlador, puedes usar este método, que de por sí es muy muy rápido, pues no estás usando alguna clase externa (AMS) o vistas (JBuilder). Pero lamentablemente, si tienes un objeto JSON con una estructura demasiado grande o necesitas cierta flexibilidad, entonces deberías elegir entre AMS o JBuilder.

¿Por dónde empezar?… JBuilder, to_json() o AMS, todos son relativamente fáciles; sin embargo, yo decidí empezar con JBuilder por parecerse mucho a la forma en que se trabaja con vistas HTML, y con esto me refiero a tener tu variable de clase @users en tu controlador y usarla en tu vista respectiva.

Para terminar

No intento imponer reglas absolutas sobre lo que usted como desarrollador debería hacer o no hacer, solo explico desde mi punto de vista las cosas que al menos para mí funcionaron y me ayudan a crecer cada día más como ruby-developer (como el caso de Rubocop).

Al final es usted el que tiene la última palabra, como en el caso de RABL, el cual le recomiendo probar y, si le parece que se adecúa a sus necesidades, entonces no dude en usarlo; al final todo se trata de gustos y colores y del tipo de proyecto en el que esté trabajando.

Si te interesa, también puedes revisar:

• Qué es y cómo crear una API en Ruby on Rails
• ¿Cómo agregar seguridad a tu API RESTful?
• ¿No sabes cómo testear un controlador en Rails? ¡Este post es para ti!

Muchas gracias por leer el post; recuerde que si le gustó, no dude en compartirlo y recomendarlo con sus amigos.