Rails 8 en 2026: Solid Queue, Solid Cache y sin Node.js como dependencia

Rails 8.0 salió en noviembre de 2024 y trajo algo que muchos llevaban tiempo pidiendo: la posibilidad de montar una aplicación completa, con jobs asíncronos, caché y WebSockets, sin instalar Redis ni Memcached, y sin tocar Node.js. El kit de herramientas se llama Solid y, aunque el nombre suena a marketing, la propuesta técnica es bastante sólida.

El problema que resuelve Solid Queue

Rails lleva años con Active Job como capa de abstracción para jobs en background. El problema era que Active Job necesita un backend: Sidekiq (que usa Redis), Resque (también Redis), Delayed Job (base de datos, pero lento) o GoodJob (PostgreSQL, más reciente). Cada opción añade una dependencia de infraestructura o tiene sus propias limitaciones.

Solid Queue usa la base de datos relacional de la aplicación como backend, pero con un diseño que evita los problemas clásicos de polling. Usa SELECT ... FOR UPDATE SKIP LOCKED, disponible en PostgreSQL, MySQL 8+ y MariaDB 10.6+, para que múltiples workers puedan sacar jobs de la cola sin bloquearse entre ellos.

# config/application.rb
config.active_job.queue_adapter = :solid_queue

# En un modelo o controlador, exactamente igual que con Sidekiq
class EnviarEmailJob < ApplicationJob
  queue_as :default

  def perform(usuario_id)
    usuario = Usuario.find(usuario_id)
    UsuarioMailer.bienvenida(usuario).deliver_now
  end
end

# Encolar
EnviarEmailJob.perform_later(usuario.id)
EnviarEmailJob.set(wait: 5.minutes).perform_later(usuario.id)

La API es exactamente la misma que con cualquier otro backend de Active Job. Si más adelante necesitas migrar a Sidekiq porque tienes millones de jobs diarios, el cambio es una línea de configuración.

Solid Cache: caché sin Memcached

El patrón habitual en Rails era usar Memcached o Redis como store de caché. Solid Cache hace lo mismo pero usando la base de datos, con un diseño pensado para aprovechar la caché de disco del sistema operativo y SSDs modernos.

La propuesta puede sonar extraña: ¿la base de datos no es más lenta que Memcached? Depende. Para muchos patrones de caché en aplicaciones Rails medianas, Solid Cache es suficientemente rápido y elimina una pieza de infraestructura. Shopify lo usa en producción con buenos resultados.

# config/environments/production.rb
config.cache_store = :solid_cache_store

# Uso idéntico al cache store habitual
Rails.cache.write("usuario_#{id}", datos, expires_in: 1.hour)
Rails.cache.read("usuario_#{id}")
Rails.cache.fetch("usuario_#{id}", expires_in: 1.hour) do
  Usuario.find(id).to_json
end

Solid Cache gestiona automáticamente la expiración y tiene un sistema de limpieza en background para que la tabla no crezca sin control.

Solid Cable: WebSockets sobre base de datos

Action Cable, el sistema de WebSockets de Rails, también necesitaba un adapter para gestionar la suscripción a canales. El adapter por defecto usaba Redis. Solid Cable resuelve lo mismo con la base de datos.

Para aplicaciones con tráfico moderado de WebSockets, Solid Cable funciona bien. Para casos de alta concurrencia con miles de conexiones simultáneas, Redis sigue siendo la opción más robusta.

Sin Node.js: Propshaft y Import Maps

Otra novedad importante de Rails 8 es que Propshaft pasa a ser el asset pipeline por defecto, sustituyendo a Sprockets. Propshaft es más simple: no transpila ni minifica, solo añade hashes a los nombres de los ficheros para el cache-busting.

Combinado con Import Maps (que ya llegó en Rails 7), esto significa que puedes escribir JavaScript moderno directamente en el navegador sin webpack, esbuild ni ningún bundler de Node.js. Los módulos ES6 se cargan directamente:

# config/importmap.rb
pin "application", preload: true
pin "@hotwired/turbo-rails", to: "turbo.min.js", preload: true
pin "@hotwired/stimulus", to: "stimulus.min.js", preload: true
pin "@hotwired/stimulus-loading", to: "stimulus-loading.js"
pin_all_from "app/javascript/controllers", under: "controllers"

No todo el mundo puede prescindir de Node.js: si tienes TypeScript, React o un sistema de componentes complejo, sigues necesitando un bundler. Pero para aplicaciones con Hotwire y algo de Stimulus, la pila es más ligera.

El generador de autenticación nativo

Rails 8 incluye un generador de autenticación que crea el sistema básico de login sin Devise ni otras gemas. Un solo comando genera modelos, controladores, vistas y sesiones:

rails generate authentication

Esto crea User, Session, un SessionsController, vistas de login/logout y el concern Authentication con los helpers habituales. No incluye registro de usuarios ni recuperación de contraseña (eso lo añades tú), pero el esqueleto es suficiente para muchas aplicaciones internas o APIs.

Si tu proyecto necesita autenticación social (Google, GitHub) o características avanzadas como OTP o magic links, Devise o Rodauth siguen siendo las opciones más completas. Pero para casos sencillos, el generador nativo evita añadir dependencias.

Compatibilidad con Rails 7

La migración desde Rails 7.x a Rails 8 es más tranquila que saltos anteriores. Los cambios más comunes que encontrarás:

  • Sprockets ya no viene por defecto; si lo usas, añádelo explícitamente al Gemfile.
  • Si tienes tests que usan fixtures de caché con Redis, necesitas ajustarlos si migras a Solid Cache.
  • Algunas gemas que dependen del asset pipeline pueden necesitar actualización.

La guía de upgrading oficial de Rails documenta cada cambio con detalle. Lo habitual es pasar primero a Rails 7.2 (si no estás ya) y de ahí a 8.0.

Si quieres ver cómo Rails 8 gestiona el frontend sin JavaScript pesado, el artículo sobre helpers de iteradores en JavaScript da contexto sobre lo que sí puedes hacer con JS moderno y sin frameworks.

¿Merece la pena actualizar?

Si tienes una aplicación Rails 7 en producción que usa Redis solo para Sidekiq y el cache store, Rails 8 con la suite Solid te permite simplificar la infraestructura sin cambiar prácticamente nada del código de aplicación. Menos servicios que mantener, menos costes en hosting, menos puntos de fallo.

Para proyectos nuevos, Rails 8 es la opción más directa: el stack por defecto ya incluye todo lo necesario para una aplicación con jobs, caché y WebSockets sin configuración adicional.

Imagen: Pexels / luis gomes

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP