<%= simple_format @article.body %>
<%# Partial para los comentarios %>
<%= render @comments %>
```
El flujo típico: la petición llega al Router, que la despacha al Controller adecuado. El Controller interactúa con el Model para recuperar o modificar los datos, luego pasa esos datos a la View para el renderizado HTML.
### Pregunta 2: ¿Qué es Active Record y cómo funciona el ORM de Rails?
Active Record es el ORM (Object-Relational Mapping) de Rails que implementa el patrón Active Record. Cada clase Model representa una tabla de la base de datos, y cada instancia representa una fila.
```ruby
# app/models/user.rb
# Active Record mapea automáticamente columnas a atributos
class User < ApplicationRecord
# La tabla 'users' se asocia automáticamente
# Columnas: id, email, name, created_at, updated_at
has_secure_password # BCrypt para la contraseña
has_many :articles, foreign_key: :author_id
has_one :profile, dependent: :destroy
has_and_belongs_to_many :roles
# Validaciones
validates :email, presence: true,
uniqueness: { case_sensitive: false },
format: { with: URI::MailTo::EMAIL_REGEXP }
# Callbacks
before_save :normalize_email
# Métodos de clase para consultas
def self.admins
joins(:roles).where(roles: { name: 'admin' })
end
private
def normalize_email
self.email = email.downcase.strip
end
end
```
```ruby
# Ejemplos de consultas Active Record
# Consola Rails o dentro de un servicio
# Creación
user = User.create!(email: 'dev@example.com', name: 'Alice', password: 'secret123')
# Lectura con condiciones
active_users = User.where(active: true).order(:name)
user = User.find_by(email: 'dev@example.com')
# Consultas encadenadas (evaluación perezosa)
recent_admins = User.admins
.where('created_at > ?', 1.month.ago)
.includes(:profile)
.limit(10)
# Prevención de N+1 con eager loading
articles = Article.includes(:author, :comments).published
# Actualización
user.update!(name: 'Alice Martin')
# Transacciones
User.transaction do
user.debit_balance!(100)
recipient.credit_balance!(100)
Payment.create!(from: user, to: recipient, amount: 100)
end
```
Active Record convierte los métodos Ruby en consultas SQL optimizadas. Los métodos como `where`, `joins`, `includes` son perezosos: la consulta solo se ejecuta al iterar o al llamar `to_a`.
### Pregunta 3: Explicar el sistema de migraciones de Rails
Las migraciones permiten versionar el esquema de la base de datos con Ruby. Son reversibles y permiten una evolución controlada de la estructura de datos.
```ruby
# db/migrate/20260203100000_create_products.rb
# Migración para crear una tabla
class CreateProducts < ActiveRecord::Migration[7.1]
def change
create_table :products do |t|
t.string :name, null: false
t.text :description
t.decimal :price, precision: 10, scale: 2, null: false
t.integer :stock_quantity, default: 0
t.references :category, null: false, foreign_key: true
t.boolean :active, default: true
t.timestamps # created_at y updated_at automáticos
end
# Índices para el rendimiento
add_index :products, :name
add_index :products, [:category_id, :active]
end
end
```
```ruby
# db/migrate/20260203110000_add_slug_to_products.rb
# Migración para modificar una tabla existente
class AddSlugToProducts < ActiveRecord::Migration[7.1]
def change
add_column :products, :slug, :string
add_index :products, :slug, unique: true
# Rellenar slugs existentes
reversible do |dir|
dir.up do
Product.find_each do |product|
product.update_column(:slug, product.name.parameterize)
end
end
end
# Hacer no nulo después del relleno
change_column_null :products, :slug, false
end
end
```
```bash
# Comandos esenciales de migración
rails db:migrate # Ejecutar migraciones pendientes
rails db:rollback # Deshacer la última migración
rails db:rollback STEP=3 # Deshacer las últimas 3 migraciones
rails db:migrate:status # Ver el estado de las migraciones
rails db:seed # Ejecutar db/seeds.rb
rails db:reset # Drop, create, migrate, seed
```
Las migraciones deben ser reversibles. El método `change` es inteligente y puede revertir automáticamente las operaciones comunes. Para casos complejos, usar `up` y `down` por separado.
## Active Record avanzado
### Pregunta 4: ¿Cómo optimizar consultas N+1 en Rails?
El problema N+1 ocurre cuando una consulta inicial es seguida por N consultas adicionales para cargar las asociaciones. Rails ofrece varios métodos de eager loading para resolver este problema.
```ruby
# app/controllers/orders_controller.rb
class OrdersController < ApplicationController
def index
# ❌ PROBLEMA N+1: 1 consulta + N consultas por pedido
# @orders = Order.all
# En la vista: order.user.name genera una consulta por pedido
# ✅ SOLUCIÓN con includes (eager loading)
@orders = Order.includes(:user, :items)
.where(status: 'completed')
.order(created_at: :desc)
# Genera solo 3 consultas en total
end
def show
# includes: carga las asociaciones por separado (2-3 consultas)
@order = Order.includes(items: :product).find(params[:id])
# preload: fuerza la carga separada
@order = Order.preload(:items, :user).find(params[:id])
# eager_load: fuerza un LEFT OUTER JOIN (1 consulta)
@order = Order.eager_load(:items).find(params[:id])
end
end
```
```ruby
# app/models/order.rb
class Order < ApplicationRecord
belongs_to :user
has_many :items, class_name: 'OrderItem'
has_many :products, through: :items
# Scope con includes por defecto
scope :with_details, -> { includes(:user, items: :product) }
# Counter cache para evitar consultas COUNT
# Requiere: add_column :users, :orders_count, :integer, default: 0
belongs_to :user, counter_cache: true
end
```
```ruby
# Detección de N+1 con la gem Bullet (desarrollo)
# config/environments/development.rb
config.after_initialize do
Bullet.enable = true
Bullet.alert = true
Bullet.bullet_logger = true
Bullet.rails_logger = true
end
# Bullet mostrará alertas cuando:
# - Se detecte una consulta N+1
# - Haya eager loading innecesario
# - Se debería usar un counter cache
```
La regla: usar `includes` por defecto (Rails elige la estrategia óptima), `preload` cuando se quiere forzar consultas separadas, `eager_load` cuando se filtra sobre las asociaciones.
### Pregunta 5: Explicar Scopes y Query Objects en Rails
Los scopes encapsulan condiciones de consulta reutilizables. Para consultas complejas, los Query Objects ofrecen mejor organización y testabilidad.
```ruby
# app/models/product.rb
class Product < ApplicationRecord
# Scopes simples
scope :active, -> { where(active: true) }
scope :in_stock, -> { where('stock_quantity > 0') }
scope :featured, -> { where(featured: true) }
# Scopes con parámetros
scope :cheaper_than, ->(price) { where('price < ?', price) }
scope :in_category, ->(category) { where(category: category) }
# Scopes encadenables
scope :available, -> { active.in_stock }
# Scope con joins
scope :with_recent_orders, -> {
joins(:order_items)
.where('order_items.created_at > ?', 30.days.ago)
.distinct
}
# Scope con subconsulta
scope :bestsellers, -> {
where(id: OrderItem.group(:product_id)
.order('COUNT(*) DESC')
.limit(10)
.select(:product_id))
}
end
```
```ruby
# app/queries/products_search_query.rb
# Query Object para búsquedas complejas
class ProductsSearchQuery
def initialize(relation = Product.all)
@relation = relation
end
def call(params)
@relation = filter_by_category(params[:category])
@relation = filter_by_price_range(params[:min_price], params[:max_price])
@relation = filter_by_search(params[:q])
@relation = apply_sorting(params[:sort])
@relation
end
private
def filter_by_category(category)
return @relation if category.blank?
@relation.where(category_id: category)
end
def filter_by_price_range(min, max)
@relation = @relation.where('price >= ?', min) if min.present?
@relation = @relation.where('price <= ?', max) if max.present?
@relation
end
def filter_by_search(query)
return @relation if query.blank?
@relation.where('name ILIKE ? OR description ILIKE ?',
"%#{query}%", "%#{query}%")
end
def apply_sorting(sort)
case sort
when 'price_asc' then @relation.order(price: :asc)
when 'price_desc' then @relation.order(price: :desc)
when 'newest' then @relation.order(created_at: :desc)
else @relation.order(:name)
end
end
end
# Uso en el controller
@products = ProductsSearchQuery.new(Product.active).call(params)
```
Los scopes son perfectos para condiciones simples y reutilizables. Los Query Objects son adecuados para búsquedas complejas con múltiples filtros opcionales y lógica de composición.
## Routing y Controllers
### Pregunta 6: ¿Cómo funciona el routing RESTful en Rails?
Rails fomenta rutas RESTful que mapean los verbos HTTP a las acciones CRUD. El router traduce las URL en llamadas específicas al controller.
```ruby
# config/routes.rb
Rails.application.routes.draw do
# Rutas RESTful estándar (7 acciones)
resources :articles do
# Rutas anidadas
resources :comments, only: [:create, :destroy]
# Rutas de miembro (actúan sobre una instancia)
member do
post :publish
delete :archive
end
# Rutas de colección (actúan sobre la colección)
collection do
get :drafts
get :search
end
end
# Rutas de API con namespace
namespace :api do
namespace :v1 do
resources :products, only: [:index, :show, :create, :update] do
resources :reviews, shallow: true
end
end
end
# Ruta personalizada
get 'dashboard', to: 'dashboard#index'
# Restricciones de ruta
constraints(SubdomainConstraint.new) do
resources :admin_settings
end
# Ruta raíz
root 'home#index'
end
```
```bash
# rails routes - Muestra todas las rutas generadas
#
# Verb URI Pattern Controller#Action
# GET /articles articles#index
# POST /articles articles#create
# GET /articles/new articles#new
# GET /articles/:id/edit articles#edit
# GET /articles/:id articles#show
# PATCH /articles/:id articles#update
# DELETE /articles/:id articles#destroy
# POST /articles/:id/publish articles#publish
# GET /articles/drafts articles#drafts
```
Los helpers de ruta generados (`article_path(@article)`, `new_article_path`) permiten referenciar las URL de forma dinámica y mantenible.
### Pregunta 7: Explicar callbacks y filtros en los controllers
Los callbacks (before_action, after_action, around_action) permiten ejecutar código antes, después o alrededor de las acciones del controller.
```ruby
# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
# Protección CSRF habilitada por defecto
protect_from_forgery with: :exception
# Callback global para autenticación
before_action :authenticate_user!
# Manejo global de errores
rescue_from ActiveRecord::RecordNotFound, with: :not_found
rescue_from ActionController::ParameterMissing, with: :bad_request
private
def not_found
render json: { error: 'Recurso no encontrado' }, status: :not_found
end
def bad_request(exception)
render json: { error: exception.message }, status: :bad_request
end
end
```
```ruby
# app/controllers/admin/products_controller.rb
class Admin::ProductsController < ApplicationController
# Callbacks con opciones
before_action :require_admin
before_action :set_product, only: [:show, :edit, :update, :destroy]
after_action :log_activity, only: [:create, :update, :destroy]
# Callback condicional
before_action :check_stock, only: [:update], if: :stock_changed?
def create
@product = Product.new(product_params)
if @product.save
redirect_to [:admin, @product], notice: 'Producto creado.'
else
render :new, status: :unprocessable_entity
end
end
def update
if @product.update(product_params)
redirect_to [:admin, @product], notice: 'Producto actualizado.'
else
render :edit, status: :unprocessable_entity
end
end
private
def require_admin
redirect_to root_path unless current_user&.admin?
end
def set_product
@product = Product.find(params[:id])
end
def stock_changed?
params[:product][:stock_quantity].present?
end
def log_activity
ActivityLog.create!(
user: current_user,
action: action_name,
resource: @product
)
end
def product_params
params.require(:product).permit(:name, :price, :description, :stock_quantity)
end
end
```
Los callbacks se ejecutan en orden de declaración. Usar `skip_before_action` en las subclases para deshabilitar callbacks heredados. Evitar callbacks con demasiada lógica de negocio: preferir Service Objects.
## Servicios y arquitectura
### Pregunta 8: ¿Cómo implementar Service Objects en Rails?
Los Service Objects encapsulan lógica de negocio compleja que no pertenece ni a los Models ni a los Controllers. Mejoran la testabilidad y siguen el principio de responsabilidad única.
```ruby
# app/services/order_processor.rb
# Service Object con interfaz estandarizada
class OrderProcessor
def initialize(order, payment_method:)
@order = order
@payment_method = payment_method
end
def call
return failure('Pedido ya procesado') if @order.processed?
ActiveRecord::Base.transaction do
validate_stock!
process_payment!
update_inventory!
send_confirmation!
@order.update!(status: 'completed', processed_at: Time.current)
end
success(@order)
rescue PaymentError => e
failure("Fallo en el pago: #{e.message}")
rescue InsufficientStockError => e
failure("Stock insuficiente: #{e.message}")
end
private
def validate_stock!
@order.items.each do |item|
unless item.product.stock_quantity >= item.quantity
raise InsufficientStockError, item.product.name
end
end
end
def process_payment!
result = PaymentGateway.charge(
amount: @order.total,
method: @payment_method,
description: "Pedido ##{@order.id}"
)
raise PaymentError, result.error unless result.success?
@order.update!(payment_reference: result.transaction_id)
end
def update_inventory!
@order.items.each do |item|
item.product.decrement!(:stock_quantity, item.quantity)
end
end
def send_confirmation!
OrderMailer.confirmation(@order).deliver_later
end
def success(data)
Result.new(success: true, data: data)
end
def failure(error)
Result.new(success: false, error: error)
end
Result = Struct.new(:success, :data, :error, keyword_init: true) do
def success? = success
def failure? = !success
end
end
```
```ruby
# app/controllers/orders_controller.rb
class OrdersController < ApplicationController
def create
@order = current_user.orders.build(order_params)
if @order.save
result = OrderProcessor.new(@order, payment_method: params[:payment_method]).call
if result.success?
redirect_to @order, notice: '¡Pedido confirmado!'
else
@order.update!(status: 'payment_failed')
flash.now[:alert] = result.error
render :new, status: :unprocessable_entity
end
else
render :new, status: :unprocessable_entity
end
end
end
```
El patrón Service Object sigue una convención simple: una clase, una responsabilidad, un método público `call`. Devolver un objeto Result permite manejar limpiamente éxito y fallo.
### Pregunta 9: Explicar Concerns en Rails
Los Concerns permiten extraer y compartir código entre Models o Controllers. Utilizan `ActiveSupport::Concern` para una sintaxis de inclusión limpia.
```ruby
# app/models/concerns/sluggable.rb
# Concern reutilizable para generar slugs
module Sluggable
extend ActiveSupport::Concern
included do
# Código ejecutado al incluir
before_validation :generate_slug, if: :should_generate_slug?
validates :slug, presence: true, uniqueness: true
end
# Métodos de clase
class_methods do
def find_by_slug!(slug)
find_by!(slug: slug)
end
def sluggable_source(column = :title)
@sluggable_source = column
end
def sluggable_source_column
@sluggable_source || :title
end
end
# Métodos de instancia
def to_param
slug
end
private
def should_generate_slug?
slug.blank? || send("#{self.class.sluggable_source_column}_changed?")
end
def generate_slug
source = send(self.class.sluggable_source_column)
return if source.blank?
base_slug = source.parameterize
self.slug = unique_slug(base_slug)
end
def unique_slug(base)
slug = base
counter = 1
while self.class.where(slug: slug).where.not(id: id).exists?
slug = "#{base}-#{counter}"
counter += 1
end
slug
end
end
```
```ruby
# app/models/article.rb
class Article < ApplicationRecord
include Sluggable
sluggable_source :title # Opcional, :title por defecto
end
# app/models/product.rb
class Product < ApplicationRecord
include Sluggable
sluggable_source :name
end
```
```ruby
# app/controllers/concerns/pagination.rb
# Concern para controllers
module Pagination
extend ActiveSupport::Concern
included do
helper_method :page_param, :per_page_param
end
private
def paginate(relation)
relation.page(page_param).per(per_page_param)
end
def page_param
params[:page]&.to_i || 1
end
def per_page_param
[params[:per_page]&.to_i || 25, 100].min
end
end
```
Los Concerns son útiles para código verdaderamente compartido. Evitar crear Concerns solo para "acortar" un Model: eso oculta la complejidad sin reducirla.
## Testing con RSpec
### Pregunta 10: ¿Cómo estructurar los tests RSpec en Rails?
RSpec es el framework de testing estándar para Rails. Una buena estructura de tests incluye Model specs, Controller specs, Service specs y tests de integración.
```ruby
# spec/models/user_spec.rb
require 'rails_helper'
RSpec.describe User, type: :model do
# Factories con FactoryBot
let(:user) { build(:user) }
let(:admin) { build(:user, :admin) }
describe 'validations' do
it { is_expected.to validate_presence_of(:email) }
it { is_expected.to validate_uniqueness_of(:email).case_insensitive }
it 'valida el formato del email' do
user.email = 'invalid'
expect(user).not_to be_valid
expect(user.errors[:email]).to include('is invalid')
end
end
describe 'associations' do
it { is_expected.to have_many(:articles).dependent(:destroy) }
it { is_expected.to have_one(:profile) }
it { is_expected.to belong_to(:organization).optional }
end
describe '#full_name' do
it 'devuelve el nombre y apellido combinados' do
user = build(:user, first_name: 'John', last_name: 'Doe')
expect(user.full_name).to eq('John Doe')
end
it 'maneja la ausencia de apellido' do
user = build(:user, first_name: 'John', last_name: nil)
expect(user.full_name).to eq('John')
end
end
describe '.active' do
it 'devuelve solo los usuarios activos' do
active = create(:user, active: true)
inactive = create(:user, active: false)
expect(User.active).to include(active)
expect(User.active).not_to include(inactive)
end
end
end
```
```ruby
# spec/services/order_processor_spec.rb
require 'rails_helper'
RSpec.describe OrderProcessor do
let(:user) { create(:user) }
let(:product) { create(:product, stock_quantity: 10, price: 100) }
let(:order) { create(:order, user: user, items: [build(:order_item, product: product, quantity: 2)]) }
subject { described_class.new(order, payment_method: 'card') }
describe '#call' do
context 'cuando el pedido es válido' do
before do
allow(PaymentGateway).to receive(:charge).and_return(
OpenStruct.new(success?: true, transaction_id: 'txn_123')
)
end
it 'procesa el pedido correctamente' do
result = subject.call
expect(result).to be_success
expect(order.reload.status).to eq('completed')
end
it 'decrementa el stock del producto' do
expect { subject.call }.to change { product.reload.stock_quantity }.by(-2)
end
it 'envía el correo de confirmación' do
expect { subject.call }
.to have_enqueued_mail(OrderMailer, :confirmation)
.with(order)
end
end
context 'cuando falla el pago' do
before do
allow(PaymentGateway).to receive(:charge).and_return(
OpenStruct.new(success?: false, error: 'Card declined')
)
end
it 'devuelve un resultado de fallo' do
result = subject.call
expect(result).to be_failure
expect(result.error).to include('Card declined')
end
it 'no actualiza el estado del pedido' do
expect { subject.call }.not_to change { order.reload.status }
end
end
end
end
```
```ruby
# spec/requests/api/v1/products_spec.rb
require 'rails_helper'
RSpec.describe 'API V1 Products', type: :request do
let(:user) { create(:user) }
let(:headers) { { 'Authorization' => "Bearer #{user.api_token}" } }
describe 'GET /api/v1/products' do
let!(:products) { create_list(:product, 3, :active) }
it 'devuelve la lista de productos' do
get '/api/v1/products', headers: headers
expect(response).to have_http_status(:ok)
expect(json_response['data'].size).to eq(3)
end
it 'filtra por categoría' do
category = create(:category)
categorized = create(:product, category: category)
get '/api/v1/products', params: { category_id: category.id }, headers: headers
expect(json_response['data'].map { |p| p['id'] }).to eq([categorized.id])
end
end
describe 'POST /api/v1/products' do
let(:valid_params) do
{ product: { name: 'Producto Nuevo', price: 99.99, category_id: create(:category).id } }
end
it 'crea un producto nuevo' do
expect {
post '/api/v1/products', params: valid_params, headers: headers
}.to change(Product, :count).by(1)
expect(response).to have_http_status(:created)
end
end
end
```
Buenas prácticas: usar `let` para los datos, `describe` para métodos/contextos, `context` para condiciones, e `it` para aserciones específicas. Cada test debe probar una sola cosa.
### Pregunta 11: ¿Cómo usar factories con FactoryBot?
FactoryBot permite crear datos de prueba de forma declarativa y mantenible. Las factories reemplazan a las fixtures estáticas.
```ruby
# spec/factories/users.rb
FactoryBot.define do
factory :user do
# Secuencias para garantizar unicidad
sequence(:email) { |n| "user#{n}@example.com" }
first_name { Faker::Name.first_name }
last_name { Faker::Name.last_name }
password { 'password123' }
confirmed_at { Time.current }
# Traits para variaciones
trait :admin do
role { 'admin' }
after(:create) do |user|
user.permissions.create!(name: 'admin_access')
end
end
trait :unconfirmed do
confirmed_at { nil }
end
trait :with_profile do
after(:create) do |user|
create(:profile, user: user)
end
end
trait :with_articles do
transient do
articles_count { 3 }
end
after(:create) do |user, evaluator|
create_list(:article, evaluator.articles_count, author: user)
end
end
# Factory heredada
factory :admin_user do
admin
with_profile
end
end
end
```
```ruby
# spec/factories/orders.rb
FactoryBot.define do
factory :order do
user
status { 'pending' }
trait :with_items do
transient do
items_count { 2 }
end
after(:create) do |order, evaluator|
create_list(:order_item, evaluator.items_count, order: order)
order.recalculate_total!
end
end
trait :completed do
status { 'completed' }
processed_at { Time.current }
with_items
end
trait :high_value do
after(:create) do |order|
create(:order_item, order: order, quantity: 10, unit_price: 500)
order.recalculate_total!
end
end
end
end
```
```ruby
# Uso en tests
RSpec.describe OrderProcessor do
# build: instancia no persistida
let(:user) { build(:user) }
# create: persistida en BD
let(:order) { create(:order, :with_items, user: user) }
# create_list: múltiples instancias
let(:products) { create_list(:product, 5) }
# Combinar traits
let(:admin) { create(:user, :admin, :with_profile) }
# Sobrescribir atributos
let(:expensive_order) { create(:order, :with_items, items_count: 10) }
# build_stubbed: más rápido, para tests unitarios
let(:stubbed_user) { build_stubbed(:user) }
end
```
Preferir `build` o `build_stubbed` sobre `create` cuando la persistencia no es necesaria: esto acelera significativamente los tests.
## Background Jobs
### Pregunta 12: ¿Cómo usar Active Job y Sidekiq en Rails?
Active Job ofrece una interfaz unificada para trabajos en segundo plano, sin importar el backend (Sidekiq, Resque, etc.). Sidekiq es la opción popular por su rendimiento con Redis.
```ruby
# app/jobs/process_order_job.rb
class ProcessOrderJob < ApplicationJob
queue_as :default
# Configuración de reintentos
retry_on ActiveRecord::Deadlocked, wait: 5.seconds, attempts: 3
retry_on Net::OpenTimeout, wait: :polynomially_longer, attempts: 10
discard_on ActiveJob::DeserializationError
# Opciones de Sidekiq (si el backend es Sidekiq)
sidekiq_options retry: 5, backtrace: true
def perform(order_id)
order = Order.find(order_id)
OrderProcessor.new(order).call
rescue ActiveRecord::RecordNotFound
# Pedido eliminado entre el encolado y la ejecución
Rails.logger.warn("Order #{order_id} not found, skipping job")
end
end
```
```ruby
# app/jobs/batch_email_job.rb
class BatchEmailJob < ApplicationJob
queue_as :mailers
# Limitación de tasa con Sidekiq Enterprise o gem throttle
sidekiq_options throttle: { threshold: 100, period: 1.minute }
def perform(user_ids, template_id)
template = EmailTemplate.find(template_id)
User.where(id: user_ids).find_each do |user|
UserMailer.custom_email(user, template).deliver_later
end
end
end
```
```ruby
# Encolar trabajos
# Inmediato
ProcessOrderJob.perform_later(order.id)
# Diferido
ProcessOrderJob.set(wait: 5.minutes).perform_later(order.id)
# A una hora específica
ProcessOrderJob.set(wait_until: Date.tomorrow.noon).perform_later(order.id)
# Cola específica
ProcessOrderJob.set(queue: :critical).perform_later(order.id)
# Síncrono (para tests o depuración)
ProcessOrderJob.perform_now(order.id)
```
```ruby
# config/sidekiq.yml
:concurrency: 10
:queues:
- [critical, 3] # Alta prioridad, peso 3
- [default, 2] # Prioridad media, peso 2
- [mailers, 1] # Prioridad baja, peso 1
- [low, 1]
:schedule:
cleanup_job:
cron: '0 3 * * *' # Cada día a las 3am
class: CleanupJob
```
Active Job abstrae el backend, pero acceder a funcionalidades específicas (batches, rate limiting) suele requerir acoplamiento con el backend elegido.
## Desarrollo de API
### Pregunta 13: ¿Cómo construir una API RESTful con Rails?
Rails facilita la construcción de APIs JSON con Controllers API-only y serializadores. Una buena API está versionada, documentada y es segura.
```ruby
# app/controllers/api/v1/base_controller.rb
module Api
module V1
class BaseController < ActionController::API
include ActionController::HttpAuthentication::Token::ControllerMethods
before_action :authenticate_token!
rescue_from ActiveRecord::RecordNotFound, with: :not_found
rescue_from ActiveRecord::RecordInvalid, with: :unprocessable_entity
rescue_from ActionController::ParameterMissing, with: :bad_request
private
def authenticate_token!
authenticate_or_request_with_http_token do |token, options|
@current_user = User.find_by(api_token: token)
end
end
def current_user
@current_user
end
def not_found(exception)
render json: { error: 'Recurso no encontrado', details: exception.message },
status: :not_found
end
def unprocessable_entity(exception)
render json: { error: 'Validación fallida', details: exception.record.errors },
status: :unprocessable_entity
end
def bad_request(exception)
render json: { error: 'Petición incorrecta', details: exception.message },
status: :bad_request
end
end
end
end
```
```ruby
# app/controllers/api/v1/products_controller.rb
module Api
module V1
class ProductsController < BaseController
before_action :set_product, only: [:show, :update, :destroy]
def index
@products = Product.active
.includes(:category)
.page(params[:page])
.per(params[:per_page] || 20)
render json: {
data: ProductSerializer.new(@products).serializable_hash,
meta: pagination_meta(@products)
}
end
def show
render json: ProductSerializer.new(@product, include: [:category, :reviews])
end
def create
@product = Product.new(product_params)
@product.save!
render json: ProductSerializer.new(@product), status: :created
end
def update
@product.update!(product_params)
render json: ProductSerializer.new(@product)
end
def destroy
@product.destroy!
head :no_content
end
private
def set_product
@product = Product.find(params[:id])
end
def product_params
params.require(:product).permit(:name, :description, :price, :category_id)
end
def pagination_meta(collection)
{
current_page: collection.current_page,
total_pages: collection.total_pages,
total_count: collection.total_count
}
end
end
end
end
```
```ruby
# app/serializers/product_serializer.rb
# Con la gem jsonapi-serializer
class ProductSerializer
include JSONAPI::Serializer
attributes :id, :name, :description, :price, :created_at
attribute :formatted_price do |product|
"$#{product.price.to_f.round(2)}"
end
belongs_to :category
has_many :reviews
link :self do |product|
Rails.application.routes.url_helpers.api_v1_product_url(product)
end
end
```
Buenas prácticas de API: versionar mediante namespace, usar códigos HTTP apropiados, paginar las colecciones y proporcionar mensajes de error claros.
### Pregunta 14: ¿Cómo implementar autenticación JWT en Rails?
JWT (JSON Web Tokens) es un método de autenticación stateless popular para APIs. El token codifica la identidad y validez del usuario.
```ruby
# app/services/jwt_service.rb
class JwtService
SECRET_KEY = Rails.application.credentials.secret_key_base
ALGORITHM = 'HS256'.freeze
class << self
def encode(payload, exp = 24.hours.from_now)
payload[:exp] = exp.to_i
payload[:iat] = Time.current.to_i
JWT.encode(payload, SECRET_KEY, ALGORITHM)
end
def decode(token)
decoded = JWT.decode(token, SECRET_KEY, true, algorithm: ALGORITHM)
HashWithIndifferentAccess.new(decoded.first)
rescue JWT::ExpiredSignature
raise AuthenticationError, 'Token expirado'
rescue JWT::DecodeError
raise AuthenticationError, 'Token inválido'
end
end
end
```
```ruby
# app/controllers/api/v1/auth_controller.rb
module Api
module V1
class AuthController < ActionController::API
def login
user = User.find_by(email: params[:email])
if user&.authenticate(params[:password])
token = JwtService.encode(user_id: user.id)
render json: {
token: token,
user: UserSerializer.new(user),
expires_at: 24.hours.from_now
}
else
render json: { error: 'Credenciales inválidas' }, status: :unauthorized
end
end
def refresh
token = JwtService.encode(user_id: current_user.id)
render json: { token: token, expires_at: 24.hours.from_now }
end
end
end
end
```
```ruby
# app/controllers/concerns/jwt_authenticatable.rb
module JwtAuthenticatable
extend ActiveSupport::Concern
included do
before_action :authenticate_jwt!
end
private
def authenticate_jwt!
header = request.headers['Authorization']
token = header&.split(' ')&.last
raise AuthenticationError, 'Token ausente' unless token
decoded = JwtService.decode(token)
@current_user = User.find(decoded[:user_id])
rescue AuthenticationError => e
render json: { error: e.message }, status: :unauthorized
rescue ActiveRecord::RecordNotFound
render json: { error: 'Usuario no encontrado' }, status: :unauthorized
end
def current_user
@current_user
end
end
```
Para producción, considerar: refresh tokens, blacklisting de tokens al cerrar sesión y tiempos de expiración cortos. Gems como `devise-jwt` simplifican la implementación.
## Caché y rendimiento
### Pregunta 15: ¿Cómo implementar caché en Rails?
Rails ofrece varios niveles de caché: fragment caching, Russian Doll caching, low-level caching. La elección depende del caso de uso.
```ruby
# config/environments/production.rb
config.action_controller.perform_caching = true
config.cache_store = :redis_cache_store, {
url: ENV['REDIS_URL'],
namespace: 'myapp:cache',
expires_in: 1.day,
race_condition_ttl: 10.seconds
}
```
```erb
<%# app/views/products/index.html.erb %>
<%# Fragment caching con clave de caché automática %>
<% @products.each do |product| %>
<%# Caché basada en updated_at del producto %>
<% cache product do %>
<%= render product %>
<% end %>
<% end %>
<%# Russian Doll caching - caché anidada %>
<% cache ['v1', @category] do %>