- El equipo de Hardcover migró a Ruby on Rails + Inertia.js debido a problemas de rendimiento en una arquitectura basada en Next.js, costos elevados y menor velocidad de desarrollo
- Eligieron Inertia.js para cumplir con los requisitos de SSR con soporte para SEO, conexión directa a la base de datos y mantener React
- El detonante final del cambio fue el aumento inesperado de costos en Vercel y Cloud Run, junto con la incertidumbre del caché en Next.js
- Inertia.js resultó ser la forma ideal de conectar un backend en Rails con un frontend en React, facilitando el SSR y la gestión del caché
- Después de la migración, mejoraron las puntuaciones de Google Pagespeed y SEO, y aumentaron el tiempo de visita al sitio y la visibilidad en búsquedas
Contexto del cambio
- Al inicio eligieron Next.js con soporte de SEO y SSR y construyeron una arquitectura basada en una API GraphQL
- La mayor parte de los datos se solicitaba desde el navegador del lado del cliente, mientras que los datos estáticos se almacenaban en caché en el servidor
- Con el tiempo, la falta de caché provocó un aumento de solicitudes a la API, una caída de rendimiento y una disminución en la velocidad del entorno de desarrollo
Problemas que surgieron con Next.js
- Incluso tras cambiar a App Router, la mejora de velocidad fue mínima; las solicitudes POST de Apollo no se almacenaban en caché, así que no hubo el efecto esperado
- Con un cambio en la política de precios de Vercel, el costo mensual subió de $30 a $354
- Cloud Run también era barato al principio, pero llegó a subir hasta $524
- Era difícil entender la estructura de caché de Next.js, por lo que no podían administrarla de forma eficiente
- La velocidad de desarrollo cayó de forma notable, dificultando el onboarding de nuevas personas al equipo
Por qué eligieron Rails + Inertia.js
- Querían mantener SSR y al mismo tiempo obtener los datos directamente desde la base de datos
- Querían seguir usando React y revisaron Remix, react-rails y react_on_rails, pero al final adoptaron inertia-rails
- Inertia.js permite usar el routing de Rails sin routing en el frontend, y además facilita el SSR
- En el controlador manejan el renderizado con
inertia: 'nombre_de_página', y el caché se implementa con Rails.cache.fetch
- En los componentes de React reciben las props con
usePage()
Estructura de SSR y build
- Para SSR, en
application.tsx manejan la bifurcación entre hydrateRoot y createRoot
- Operan Vite como un servidor independiente y cuentan con hot reload durante el desarrollo
- Automatizaron el despliegue de Rails + Vite con Docker y Kamal, separando staging y production
- En el despliegue ejecutan el comando
make deploy, y usan CloudFlare como asset host para optimizar el caché
Efectos del cambio
- Tras desplegar la migración el 18 de marzo de 2025, aumentó la visibilidad en Google y mejoró la velocidad de las páginas
- El Total Blocking Time mejoró de forma considerable, elevando la puntuación de Pagespeed
- El tiempo promedio de permanencia de los visitantes mostró una tendencia al alza, de 3 minutos a 6 minutos
- El tráfico se mantuvo estable y el número de registros de usuarios también se mantuvo de forma consistente
Retos y mejoras pendientes
- Sigue habiendo problemas con la reutilización de layouts compartidos y con el rerenderizado completo de cada página
- Depurar SSR es difícil y la configuración del entorno es compleja
- Hay poca documentación sobre la combinación de Inertia.js con Rails, por lo que resolvieron varios temas a través de la comunidad de Discord
- Necesitan adaptarse al enfoque de Inertia en lugar de Suspense
- Actualmente siguen usando Hasura, por lo que todavía no aprovechan algunas funciones de Inertia como form y flash
Conclusión y expectativas
- Con una estructura que integra de forma natural React + Rails, mejoraron la productividad de desarrollo y la mantenibilidad
- Con la elección de Inertia.js lograron asegurar velocidad, SSR y seguridad de tipos al mismo tiempo
- A futuro planean liberar esto como open source y atraer contribuidores
2 comentarios
Hay controversia porque, al usar
Linken next.js, para poder usar React Server Components se genera y procesa algo como?_rsc=1ip3ien la URL. También se dice que los costos de uso del CDN se dispararon, y aunque el equipo de desarrollo de next.js está al tanto de este problema, todavía no está definido de qué manera ni cuándo se resolverá.Opiniones de Hacker News
El renderizado del lado del servidor (SSR) nunca desapareció, y la web apenas ahora está recordando por qué era el valor por defecto. El primer renderizado y el SEO siguen siendo mejores cuando el marcado llega desde el servidor. Distintos frameworks como Rails + Turbo, HTMX, Phoenix LiveView y React Server Components toman SSR como base. La mayoría de los dashboards y apps CRUD no necesitan un router del lado del cliente, estado global ni un bundle de hidratación de 200 kB, sino solo reemplazo parcial de HTML
El verdadero motor es el costo de la complejidad. Cada línea de JS del cliente trae herramientas de build, ruido de auditorías de npm y riesgos de la cadena de suministro. Reducir esa carga mejora al mismo tiempo el rendimiento y la seguridad. Claro, apps como Figma o Gmail siguen beneficiándose de una lógica pesada en el cliente. Por eso está apareciendo el patrón de “HTML por defecto, JS solo donde haga falta”. Hay que pensar en islas, no en una SPA completa
Así que sí hay un regreso al servidor, pero no es nostalgia por el PHP de 2004. Se trata de ajustar JavaScript con criterio y dejar que HTML haga el 90% del trabajo aburrido que siempre ha hecho bien
Usamos NextJS en algunos proyectos, pero ya lo estamos retirando gradualmente. Hay varias razones, pero algunos factores principales son estos
La historia de autenticación es complicada. next-auth tenía algunas limitaciones, así que terminamos usando iron-session. Por ejemplo, no podíamos usar dominios dinámicos de proveedores de identidad, así que tuvimos que hacernos cargo de todo el flujo openid. Era posible, pero fue una pérdida de tiempo inesperada en un framework supuestamente maduro
Como el servidor de NextJS no era nuestro gateway principal de API, tuvimos que hacer proxy de todas las solicitudes. La documentación no era clara, y además sumó problemas aleatorios como timeouts de requests, tamaño máximo de headers, etc.
El framework empujaba de forma muy agresiva hacia la nube, y eso chocaba con nuestros objetivos
Los maintainers no fueron especialmente útiles. Usamos otras herramientas/frameworks a pesar de sus defectos porque sus maintainers son muy accesibles y ayudan mucho (gracias a Chillicream/HotChocolate)
Recuerdo haber leído el año pasado una entrada de blog que decía que el SEO había mejorado al pasar del pages router al app router de Next.js. Esta vez estamos migrando de Next a React+Inertia.js por el aumento de costos de Vercel. Desplegar la misma app en nuestro propio VPS en vez de un proveedor cloud resolvería el problema. Pero no entiendo por qué querrían complejidad. Me pregunto si una app para seguir libros realmente necesita GraphQL, un framework frontend separado y un proceso de build complejo, o si se habría resuelto desplegando desde el inicio una sola app de RoR con plantillas HTML en un VPS
Cada vez que veo artículos y discusiones sobre la web y el stack, termino haciéndome la pregunta: “¿qué problema real se está resolviendo?”. La respuesta siempre es “mostrar texto en una pantalla”
Me pregunto qué hace la gente cuando quiere un full stack en JS, especialmente si hay una DB de por medio. La situación de los ORM está bastante fragmentada, o tienes que escribir SQL puro. Y aun así todavía hay que decidir el backend. ¿Usar express? Next.js es conocido, pero parece tener una agenda cuestionable. Remix, Astro, TanStack, etc. Todo se siente confuso porque siempre hay que volver a ajustar y reevaluar qué usar
En proyectos personales, muchas veces termino volviendo a Ruby on Rails. Siempre es un gusto. En cambio, para proyectos profesionales no sirve tanto porque hay muy pocos desarrolladores de Rails disponibles (comparado con JS). Elegir JS y muchas veces Java para el backend no es irresponsable
Me pregunto si alguien más siente algo parecido
Los desarrolladores frontend y backend no se han entendido bien durante mucho tiempo
Históricamente, como desarrollador backend, odiaba Html/JS/CSS. Es un paradigma significativamente distinto de Swing/Awt, WinForms, Android UX, etc. Solo eso ya me frustraba y me hacía quedarme en backend. Para aprender frontend había que aprender esas tres cosas. Recién ahora me estoy acostumbrando
Pero los desarrolladores frontend tenían que aprender “otro lenguaje”. Muchos lenguajes tienen sistemas de build distintos/molestos comparados con nvm. Y como sabe cualquiera que haya cambiado de lenguaje, también hay que aprender frameworks nuevos, paradigmas, etc.
Entonces algunos se dieron cuenta de que podían empujar JavaScript al backend. Tenía muchas desventajas, pero para la gente que “saca el trabajo”, especialmente en el mundo de “agrega más servidores” y “¡el dinero de VC es gratis! ¡quémenlo en infraestructura!”, esas desventajas no eran algo de qué preocuparse
Pero los desarrolladores frontend, ahora “full stack developers”, aunque en realidad más bien “developers de todo en JavaScript”, siguieron creando de formas visibles. Eso se refleja hoy en las vacantes de LinkedIn, que piden roles de Next.JS/Node.JS/lo que sea. Un solo lenguaje para dominarlos a todos
Son solo algunas ideas, pero creo que está muy relacionado con por qué la gente elige Next.JS
No puedo hablar de la parte técnica (solo conozco Next.js y no Rails, así que no me queda claro si esta publicación refleja la comodidad del autor con Rails o una arquitectura más adecuada técnicamente). Pero me parece raro que una empresa con varios ingenieros de software se preocupe por costos de infraestructura de menos de 1,000 dólares al mes. Preocuparse por costos de hosting no parece sensato
Si Rails se hubiera enfocado en un verdadero soporte de primera clase para interoperabilidad con frameworks frontend, probablemente a estas alturas sería mucho más grande. Han invertido mucho esfuerzo en Hotwire, pero yo quiero usar React, y otras personas también querrán usar lo que ya conocen
Me pregunto por qué existe este debate entre Next.js y SSR. Next.js es híbrido y funciona bastante bien. A diferencia de otros frameworks SPA, Next.js genera salida HTML prerenderizada para una carga inicial rápida, ofrece switches de configuración para chunks eficientes de JS, precarga al pasar el mouse sobre links o después de renderizar la página para todos los links n+1, y carga (previa) eficiente de imágenes según breakpoints (algo que normalmente es el talón de Aquiles frente a soluciones SSR puras)
He escrito un poco de Rails, pero no termino de entender por qué tanta emoción. Estuvo perfectamente bien, pero no encontré nada especial