Rails para todo: la potencia de Rails para todo

• Rails 8 es muy útil para proyectos pequeños y para desarrolladores en solitario.
• Con la guía de inicio más reciente, es posible construir aplicaciones de nivel de producción con facilidad.
• Gracias a las mejoras en SQLite, es posible montar un entorno de base de datos robusto sin servidores adicionales.
• La integración de CI y un generador de autenticación incorporados mejora la eficiencia del desarrollo y refuerza la seguridad.
• Con un despliegue simple mediante Kamal, puedes operar el servicio de forma rápida y segura.

---

Resumen

• Con la experiencia de uso de Rails 8, sigue siendo un excelente framework web para proyectos pequeños y desarrolladores individuales.
• Gracias a la construcción rápida, el despliegue eficiente y los módulos incorporados, destaca su ventaja en productividad frente a otros frameworks.

Excelencia de la guía reciente

• La guía reciente de Getting Started with Rails está diseñada para que incluso un principiante pueda construir una app de producción.
• Aunque la instalación de Ruby sigue siendo compleja, si sigues las indicaciones de la guía, es posible montar un servicio sólido con autenticación, caché, texto enriquecido, CI y base de datos incluidos.
• Su fortaleza es no quedarse en un simple “Hello World”, sino ofrecer una base y funciones de nivel de servicio real.
• Es un punto de partida ideal para quienes no están familiarizados con Rails.

Con SQLite basta

• SQLite es una excelente herramienta por defecto, pero hasta ahora no siempre fue fácil configurarla para producción.
• Antes requería trabajo adicional como instalar gems extra, pero con Rails 8 ya puede usarse de forma estable en entorno de producción sin configuración adicional.
• No hace falta levantar PostgreSQL ni servidores adicionales, y con solid cache no se necesita un servidor de Redis.
• Con solo Rails y SQLite puedes poner un servicio en marcha y maximizar la simplicidad en implementación y la eficiencia de costos.

CI (integración continua) fácil

• En Rails 8 se incluye una configuración de CI integrada por defecto, y después del primer commit llegan notificaciones de fallos de CI.
• Se integra con GitHub Actions sin trabajo adicional y ofrece 2.000 minutos gratuitos de tiempo de ejecución al mes.
• Para un desarrollador en solitario, es un tiempo bastante amplio.

Incorporación del generador de autenticación

• Gems de autenticación como Devise eran potentes, pero su complejidad de configuración hacía que para principiantes se sintieran algo difíciles.
• En Rails 8 se agregó un generador de autenticación simple; desde la consola basta con agregar usuarios existentes para implementar fácilmente el flujo de inicio de sesión.
• El código generado es simple y fácil de leer, por lo que también es fácil de entender para quienes comienzan.

Despliegue simple y rápido con Kamal

• La responsabilidad del proceso de despliegue la asume Kamal; si editas solo una parte del archivo deploy.yml y sigues las instrucciones, puedes poner la app en funcionamiento con SSL de inmediato.
• Es una experiencia de despliegue de web app más rápida que conectar SSL en GitHub Pages.
• La combinación de CI y despliegue fácil es uno de los aspectos más destacados de Rails 8.
• Aun siguiendo solo la guía de inicio, puedes lograr una experiencia de desarrollo alineada con las mejores prácticas actuales.

Conclusión

• Rails sigue siendo un framework poderoso y en constante evolución.
• Si este año estás pensando en un proyecto nuevo, vale la pena atreverse a desarrollar con Rails 8

[aer0700]

Últimamente he visto muchos artículos sobre SQLite, y ahora esto ya subió a todo, hasta para todo: también SQLite. ¿Deberíamos decir que es un resurgimiento de lo clásico?

[GN⁺]

Comentario de Hacker News

• Últimamente he estado construyendo apps con el stack de Spring Boot y Micronaut, y también he probado frontend con React. El enfoque omakase de Rails (todo lo que incluye) se siente cada vez más valioso. Aunque sean funciones simples que vienen desde el backend, como la validación de formularios o mensajes flash, el framework no las resuelve directamente y hay que implementarlas uno mismo o buscar un tercero. Rails resuelve de antemano los problemas que vive alrededor del 90% de las apps web. No se puede decir que sea perfecto, pero en la mayoría de los casos lo incorporado por defecto es suficiente y, cuando hace falta, siempre se puede reemplazar.
  • Spring Boot casi trae por defecto la validación de formularios, y además se puede hacer inmediatamente usando anotaciones.
• Para mí, Rails y Django son excelentes frameworks. También he construido apps críticas en Python. Pero en proyectos de monolith grandes me apetece pasar a Go porque siento que el sistema de tipos y la concurrencia de Go son más fuertes. El problema es que el ecosistema de Go no logra proveer un ecosistema de frameworks como Rails o Django. En Go, para crear herramientas de red o CLI, es lo mejor, pero para construir una app web full-stack rápido todavía termino eligiendo Rails o Django. Por eso no le siento tanta fuerza al discurso de que “Rails murió”.
  • Con herramientas como ogen, a partir de un solo documento OpenAPI se puede generar automáticamente casi todo: router estático, validación de request/response, monitoreo con Prometheus, trazabilidad con OpenTelemetry, etc. También genera código de cliente y de webhooks; la autenticación queda en agregar solo una función. Combinando sqlc y el pragma user_version de SQLite, la generación de código tipado para DB y las migraciones también se vuelve fácil. Añadir SQLite también termina siendo tan simple como agregar dos líneas de import en main.go. Con las plantillas estándar de Go basta para manejar texto del frontend y con embed puedes incluir activos estáticos en el binario fácilmente. El despliegue directo también es muy simple: go build y mover el binario y listo. Gracias a las herramientas de generación de código, el backend en Go quedó muy rápido y fácil de desarrollar.
  • Yo también quería un stack de tipado estático completo, pero de forma más clara la respuesta era ASP.NET, más que Go o Rust. Aunque Microsoft está metiendo fuerte con productos nuevos (por ejemplo, Aspire.NET), en la práctica .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) es el que realmente trae batería incluida y tiene mejor confiabilidad. Requiere un cambio mental hacia OOP y DI, pero para un desarrollador con experiencia no es un problema grande.
  • El problema del ecosistema de Go no solo es la mentalidad anti-framework, sino también anti-funcionalidades modernas. Java, Kotlin, Scala, C#, F#, etc. también son buenas para desarrollar herramientas de red o CLI. Hoy en día Java AOT tampoco tiene problema de licencia comercial, y .NET tampoco está atado a Windows.
  • Me gustaría recomendar Encore. Sobre todo, cuando se integra con PaaS (como la combinación NextJS+Vercel), es muy potente. Puede que se aparte un poco de los principios centrales de Go, pero para un equipo pequeño o una sola persona es una elección excelente. Si quieres puedes desplegar con BYOC o incluso montar la capa API con stdlib sin problema. El frontend lo necesitarías con NextJS o Remix/RR7, pero la integración es muy fácil gracias a la generación automática del SDK cliente en TypeScript. Encore además trae integración de PRs con Vercel, así que también es un punto fuerte.
  • En Go, lo más cercano a una experiencia tipo Django es beego, quizá lo mejor que hay. Pero todavía siento que su madurez es insuficiente para decir que esté al nivel de Django o Rails.
  • Estoy en un proyecto con Go ahora, y me siento muy satisfecho con su código limpio. La IA ayuda mucho para superar la barrera de entrada de un framework. Aun así, para servicios orientados al cliente elegiría rails, y para herramientas internas o trabajo con datos, django me resulta más intuitivo.
  • En Ruby, con Sorbet ya puedes hacer chequeo de tipos y las capacidades de concurrencia soportadas por Fiber casi están completas. Están construyendo un nuevo servidor web llamado Falcon sobre Fiber. Aún no está al nivel de Puma, pero pronto debería estar listo para un uso serio.
  • El autor del lenguaje Stanza escribió una idea con la visión de que, para tener un framework potente (del tipo Rails), el lenguaje en sí mismo debe cumplir condiciones. Que Go o Java no tengan ese tipo de framework es resultado de una limitación del lenguaje (o del programador), de forma combinada.
  • Go desde el inicio no iba orientado a frameworks full-stack tipo Rails/Django.
  • Node/Express encaja a nivel de pico de servicio para desarrollo local, y para mí ASP.NET WebAPI/MVC es el backend ideal.
  • También vale probar goravel dev.
• Si sigues Rails Guides de principio a fin, puedes lanzar un servicio real que incluya autenticación, caché, rich text, CI y DB. Pero si bien es ideal para grandes servicios como GitHub o Airbnb, en una startup temprana meter desde el inicio todo lo de Devise, turbo y tests puede ser pérdida de tiempo. Turbo tiene la ventaja de que la carga de página mejora, pero también puede alargar el tiempo de desarrollo porque choca con funcionalidades de Devise. En la etapa de validación de idea antes de salir a producción, si no es banking/healthcare, puedes dejar tests o CI para después sin gran problema. Lo importante es no caer en el sesgo por defecto de “ya lo tengo” y decir con seguridad “ahora no lo usaré”.
  • Si estás pensando en una app SaaS, empezar con plantillas de Rails especializadas como Jumpstart Pro o Bullet Train ahorra meses de desarrollo. Ya vienen incluidas muchas bases como pagos y autenticación, y luego escalar es sencillo.
  • No comparto esa postura sobre los tests. Incluso con apps bastante pequeñas, si hay código de tests, al final ahorras tiempo. CI también suele terminar siendo un archivo de 20 líneas; en proyectos anteriores simplemente lo pegábamos.
  • CI es un elemento que acelera el ritmo de desarrollo. Conviene dejarlo desde el inicio del proyecto.
  • Me intriga saber en qué punto conviene pasar de Flask/Express/Sinatra/Gradio/Hono a Rails.
• La Rails moderna se ve mucho más brillante que antes, y me alegra. Desde Rails 2.3 y 12 años manteniendo varias apps, hoy Rails es una sensación de Pokémon evolutivo totalmente distinta. La Rails Upgrade Guide está súper bien ordenada, así que pude actualizar sin grandes refactors siguiendo todo de una vez. No es totalmente backward compatible, pero una gran ventaja es que los cambios están claramente documentados. Con ActiveStorage los adjuntos también mejoraron mucho; la transición a Webpacker fue un poco trabajosa, pero con Import Maps parece más fácil ahora. Este año tengo en agenda actualizar a 8.1.
  • Hace 4 años, para un cliente con poco presupuesto acepté hacer un recorte y elegir mantener una app Rails antigua (en tiempos de Ruby 2.3). Al final quedó súper fácil actualizar y agregar features, y estoy muy satisfecho.
• Desarrollo por cuenta propia un proyecto open source en Rails que soporta 120.000 usuarios al mes, y coincido mucho con lo que se argumenta allí. Además, la funcionalidad de adjuntos de ActiveStorage es excelente. El deploy fue principalmente con Dokku, pero espero probar Kamal. Rails sigue evolucionando y Ruby se está volviendo cada vez más rápido.
  • Si te gusta Dokku, quisiera saber si probaste Cloud Native Buildpacks. Eso permite generar imágenes OCI al instante.
• Aprender Ruby no ha sido prioridad porque en el desarrollo web no tenía tanto peso, así que lo único que conocía era Django. Me interesa comparar ambos frameworks y conocer diferencias.
  • Tengo experiencia larga en ambos ecosistemas (últimamente hice menos Rails). Django está muy ligado a Python, Rails a Ruby/gems, así que la influencia del ecosistema importa. Django admin CMS es claramente más potente que Rails, y muchas organizaciones hacen todo su CMS interno en django. Rails tiene un CLI de scaffolding enorme, así que para crear CRUD es realmente rápido. Rails está en un nivel de abstracción más alto y la estructura/arquitectura casi viene definida por Rails, así que en Django eliges mucho más. Rails está más obsesionado con DRY y evitar duplicación. Quien prioriza la intuición pythonic puede ver la magia de Rails como pesada, y los de Rails pueden sentir Python como demasiado repetitivo. En esencia, ambos tienen estilos distintos.
  • Si estuviera construyendo una app web (producto para consumidores), primero me pondría con Rails. Siento que el scaffolding y el “lanzamiento al mercado” son más fáciles (no tengo experiencia real en servicios masivos). Para herramientas internas, trabajo con datos o geografía, python/django queda mejor.
  • La gran diferencia es python vs ruby. El ecosistema de Python es gigante, y Django trae autenticación y funcionalidades de admin incorporadas.
  • En el ambiente de pruebas, creo que la experiencia en Rails es mejor. Rails trae junto a eso configuración de CI y generación de código de tests.
  • En mi experiencia, Django Admin es más flexible y fácil de usar que alternativas en Ruby. En cambio, tests y routing son mejores en Rails y las convenciones también son más fuertes. Me gusta más ActiveRecord+arel que Django ORM. (A nivel personal, escribir código en Ruby me resulta más divertido que hacerlo en Python.)
  • Ruby no es difícil de aprender, y Rails trae mucha más estructura y convenciones predefinidas que Django.
• Muchas personas tienen por Rails un apego casi amoroso; yo no lo siento tanto y a veces se me hace envidia. Cada lenguaje/framework tiene su comunidad fan, pero en Rails la fiebre se siente algo más especial.
  • Hay muchas incomodidades con las convenciones de Rails, pero si intentas lograr una productividad similar con backend JavaScript se vuelve casi imposible. Por otro lado, cuando me toca código Rails veo muchos casos donde se reimplementan funcionalidades base de Rails (por ejemplo, Active Job) por cualquier motivo. Seguir convenciones suele ser más eficiente.
• Probando SQLite en producción acabé topándome con problemas de migración. Por ejemplo, si quieres agregar restricción NOT NULL a una columna existente, hay que reescribir toda la tabla con una temporal.
  • SQLite no tiene ADD CONSTRAINT, tampoco lenguaje PL ni stored proc simple, así que terminas haciendo roundtrip en el lenguaje host, y en lenguajes estáticamente tipados especialmente.
  • Sigo pensando que Postgres es el mejor, así que no la voy a soltar fácilmente. Aun así, que Rails incluya sqlite3 como una opción de primera clase es un avance positivo.
  • La recomendación base de Rails de que SQLite es reemplazo de Redis puede existir, pero en práctica es solo para arrancar un servicio pequeño. Si luego migrarás a otra DB, no recomendaría iniciar con SQLite porque la migración siempre es dolorosa.
  • En Rails, con ActiveRecord validation puedes manejar casi todo, pero hay límite para reflejar restricciones fundamentales.
• La guía de instalación de Ruby es algo compleja. Al montar un blog con Jekyll después de 15 años me costó bastante por el uso de gem. También tuve algo de culpa, pero sentí que sería mejor si se pudiera manejar más fácil. Aun así, me dejó con ganas de retomar Ruby.
  • La configuración debe ser fácil para cualquiera. Jekyll lo aprendí rápido, pero porque ya tenía Ruby y RubyGems en mi entorno.
• Si solo usarás SQLite, litestack también vale la pena revisarlo una vez. No lo he usado en forma directa, pero planeo migrar mi proyecto personal de Postgres a litestack. El rendimiento de su benchmark me parece muy impresionante.
  • Rails 8 fortaleció bastante SQLite, así que me pregunto si litestack es realmente necesario. Me gustaría saber qué diferencia tiene.