Lanzamiento de Rails 7.1

• Al usar config.load_defaults 7.1, la serialización predeterminada de ActiveSupport::MessageVerifier y ActiveSupport::MessageEncryptor cambia de Marshal a ActiveSupport::JSON, y los mensajes Marshal existentes se pueden seguir leyendo
• ActiveRecord::Base.serialize cambia para no usar YAML de forma predeterminada, y el valor predeterminado anterior puede restaurarse con config.active_record.default_column_serializer = YAML
• Se agrega un nuevo formato de caché 7.1, que se usa como valor predeterminado en apps nuevas; las apps existentes pueden activarlo con config.load_defaults 7.1 o config.active_support.cache_format_version = 7.1
  • Los elementos escritos con el formato de caché 6.1 o 7.0 pueden leerse en el formato 7.1
  • En despliegues rolling de Rails 7.1, se debe mantener el formato de caché en el primer despliegue y activar el formato de caché 7.1 en un despliegue posterior
• Se agregan las serializaciones :message_pack y :message_pack_allow_marshal a MessageEncryptor, MessageVerifier y config.active_support.message_serializer; requieren la gem msgpack >= 1.7.0
• Se evita la exposición de valores secretos en inspect de ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration y objetos de cifrado de Active Record, y se refuerza la protección XSS en ActionView::Helpers y ERB::Util
• Se agregan a has_secure_password la validación password_challenge y el método #{attribute}_salt, y se agrega authenticate_by para reducir ataques de enumeración basados en timing según la existencia de la cuenta
• En Active Record se amplía el soporte para claves primarias compuestas y claves foráneas compuestas, con soporte para sintaxis de tuplas en where, ordenamiento por lotes con claves compuestas e inferencia de claves primarias compuestas desde el esquema
• En el soporte de PostgreSQL se agregan comandos de migración para renombrar enums, agregar valores y cambiar valores; además de soporte para exclusion constraints, unique constraints, la opción de índice INCLUDE e índices NULLS [NOT] DISTINCT
• El adaptador SQLite3 declara una mejora promedio de rendimiento de 2× con Write-Ahead-Log normal syncing mode, tamaño de journal limitado, shared memory buffer y configuración de shared cache; además, se activa por defecto el strict strings mode, que deshabilita los literales de cadena con comillas dobles
• La iteración por lotes de tablas completas en Active Record ahora usa por defecto range iteration para mejorar el rendimiento, con resultados en una prueba de 10 millones de registros en PostgreSQL: querying de 253s a 30s, updating de 288s a 124s y deleting de 268s a 83s
• El connection pooling de MemCacheStore y RedisCacheStore queda activado por defecto; para desactivarlo, se debe especificar pool: false en la configuración del cache store
• Se agrega un adaptador para el cliente de base de datos Trilogy, permitiendo usar adapter: trilogy o un DATABASE_URL con el formato trilogy://
• El formato predeterminado de etiquetas de ActiveRecord::QueryLogs cambia al formato SQLCommenter; se puede usar el formato anterior con config.active_record.query_log_tags_format = :legacy
• Entre los elementos obsoletos y eliminados se incluyen el uso del singleton ActiveSupport::Deprecation, SafeBuffer#clone_empty, el argumento rewhere de #merge, deferrable: true en add_foreign_key, TestFixtures#fixture_path y la limpieza de varias configuraciones y API obsoletas de Active Record
• Se agrega ActionView::TestCase.register_parser a las pruebas de Action View para registrar parsers de resultados renderizados, con :html y :json incluidos como parsers predeterminados

[GN⁺]

Opiniones en Hacker News

• Rails es excelente, y ahora está mejor que nunca.
  Al inicio de mi carrera usaba sobre todo Django y Laravel; después me pasé al tipo de trabajo de frontend tan común hoy en día, y este año volví a tomar un proyecto con Rails + Hotwire.
  Me sorprendió de verdad lo simple que se volvió, y es una lástima que la mayoría hayamos olvidado que podía ser así de fácil. También da miedo pensar que quienes están entrando ahora a la industria quizá nunca experimenten esta simplicidad.
  Si nunca probaste Rails o lo descartaste por cosas que escuchaste como “PHP es feo / Rails está muerto / JavaScript es un desastre”, te recomiendo ignorar por un momento lo que dicen los demás y probarlo con la mente abierta.
  Puede que no sea la mejor opción para un entorno donde 1,000 ingenieros trabajan en el mismo repositorio, pero para equipos pequeños no tiene competencia y está muy por delante de lo demás. Honestamente, quizá Laravel sea casi igual de bueno.

  • También quisiera incluir aquí a Phoenix LiveView.
    En velocidad de desarrollo inicial, creo que Rails siempre gana. Sus convenciones son tan completas y están tan bien diseñadas que casi nada se le acerca. Laravel está alcanzándolo, pero creo que todavía no llega.
    Dicho eso, LiveView escala mejor en todos los sentidos. Trae muchas cosas de base: autenticación, acceso a base de datos, colas de trabajos, mailers, herramientas completas de testing, etc.; casi no hace falta escribir JavaScript directamente, y además está BEAM, una gran máquina virtual.
    Al menos me gusta que todos estos proyectos estén dando la pelea por “dar un paso atrás”. En el trabajo usamos React y Relay, y aunque llevo mucho tiempo usando JavaScript de frontend y creo que me manejo razonablemente bien, hay demasiados obstáculos que superar y eso cansa.
  • Comparado con Django, me parece interesante que, al menos ahora, no los veas al mismo nivel. Me da curiosidad si hay razones concretas por las que prefieres Rails por encima de Django.
  • Me gusta Rails, pero en mi país casi nadie lo usa, y las empresas que sí lo usan casi siempre buscan desarrolladores de nivel mago.
    Como no consigo trabajo, tampoco puedo acumular suficiente experiencia, y al final esos magos me dejan atrás. Esas vacantes a veces llevan abiertas más de 12 meses.
    En cambio, como es donde hay demanda, estoy esparciendo más JavaScript por el mundo.
  • Muchos desarrolladores Rails que conozco se pasaron a ember.js. Es porque ember.js también es un framework basado en convenciones, no uno donde montones de plugins de terceros se rompen todo el tiempo.
    Estructuralmente, me gusta el enfoque de ember-data. Hay muchas partes que se pueden automatizar en operaciones como left joins/right joins de datasets, y también tiene un servidor mock integrado.
    Pero quizá porque funciona demasiado bien, no parece tan cool como otras cosas.
    https://emberjs.com/

• Subí una app Rails 7.0 de 13,000 líneas a 7.1, y salvo por las diferencias entre 7.0 y 7.1[0], todo funcionó cambiando solo 1 línea de código en la configuración de tests.
  Lo considero un éxito en cuanto a una ruta de actualización sencilla. Ahora la parte divertida será refactorizar parte del código para usar las nuevas funciones de 7.1.
  Por si a alguien le interesa, también actualicé a 7.1 una app de ejemplo Rails / Docker: https://github.com/nickjj/docker-rails-example
  Aunque Rails 7.1 incluye un Dockerfile, todavía hay muchas opciones para sumar, como usar Docker Compose para crear una experiencia que funcione de inmediato en desarrollo y producción, e incluir Postgres, Redis, Action Cable, Sidekiq, etc.
  [0]: https://railsdiff.org/7.0.8/7.1.0

• Estoy intentando migrar una base de código Rails 6 bastante grande, con muchísimo React encima, a la nueva forma “no” JavaScript usando Hotwire. Deséenme suerte.
  Rails es excelente cuando te mantienes dentro de los valores predeterminados, pero en cuanto te sales de ellos se convierte en una tierra de dolor.

  • Estoy trabajando en una base de código Rails 7 relativamente reciente. Al principio empezamos usando Stimulus, pero por varias razones estamos considerando pasarnos a React.
    Para contratar ingenieros de frontend, el grupo de candidatos de React es varios órdenes de magnitud mayor. También se está volviendo cada vez más difícil encontrar paquetes de JavaScript vanilla para tareas comunes y envolverlos en controladores Stimulus que encontrar paquetes de React.
    Stimulus tampoco ofrece realmente una forma de escribir pruebas unitarias para controladores. En React se puede usar jest y react-test-renderer como de costumbre.
    Además, la reciente polémica de Turbo TypeScript no inspiró confianza en la operación a largo plazo del ecosistema Hotwire.
    Aún no hemos tomado una decisión. Que Stimulus se sienta como una forma muy “a lo Rails” de escribir código de frontend es sin duda una ventaja, sobre todo para equipos pequeños que ya están familiarizados con Rails.
  • Eso de que “Rails es bueno si te mantienes en los valores predeterminados y doloroso si te sales” aplica a todos los frameworks.
    Si la aplicación es bastante simple y encaja bien con la forma de hacer las cosas del framework, el framework es excelente. Si necesitas una configuración más compleja y flexible, deberías mirar librerías.
  • Perdí la fe en la integración de JavaScript de Rails.
    Ahora renderizo del lado del servidor con slim, o lo hago solo API y separo el frontend.
    Rails cambió demasiadas veces de dirección intentando hacer JavaScript: CoffeeScript, precompilación de assets, webpack, etc.
  • No recomendaría migrar un frontend React existente a Hotwire al mismo tiempo que haces la actualización de Rails en sí. Creo que es mejor subir primero a Rails 7.1 de forma independiente.
    Como referencia, la forma de manejar JavaScript de apps de una sola página en Rails 7+ también es mucho más razonable que antes. En la práctica, puedes usar la herramienta de build que quieras separada de la app Rails.
    Durante el desarrollo tienes que ejecutar algo como yarn build --watch junto con rails s, pero personalmente no me parece mal y creo que lo vuelve mucho más simple.
    En nuestra empresa creamos software que automatiza actualizaciones de Rails, y también ofrecemos un servicio completo en el que hacemos las actualizaciones de Rails por ti. Si te interesa, puedes escribir a steve (at) infield.ai o generar un plan gratuito de actualización de Rails en https://app.infield.ai/users/sign_up. No se requiere tarjeta de crédito.
    Para más detalles, consulta https://docs.infield.ai/docs/creating-an-upgrade-path.
  • Recomiendo probar https://vite-ruby.netlify.app/guide/rails.html.
    En mi caso encajó casi directamente como reemplazo de webpack.

• Me gusta Rails y lo he usado de forma intermitente desde Rails 2.
  Es un framework muy bueno y, para alguien como yo que de vez en cuando necesita levantar un sitio web, es realmente el camino de menor resistencia.
  Pero el proceso de configurar una laptop nueva para correr Rails es doloroso. Necesitas node, y entonces también necesitas npm. Como soy desarrollador backend, no sé bien cómo configurar node ni en qué orden hacerlo.
  No es algo que haga seguido, así que cada vez se siente como una pelea. Al final lo logro, pero nunca tengo claro por qué finalmente todo encajó.
  Me gustaría que hubiera un instalador que pusiera todo lo necesario en su lugar de una sola vez para que rails simplemente funcione. El instalador de rvm configura rails sobre ruby, pero no configura el sistema node que queda por debajo.

  • Un gestor de versiones llamado asdf es bueno para administrar nodejs. No lo he probado con Ruby.
    https://asdf-vm.com/
  • Entiendo eso de “soy desarrollador backend, así que no sé configurar node”.
    Node se conoce principalmente como una herramienta de frontend y Rails también lo usa para eso, pero, si mal no recuerdo, Node fue creado al menos al principio para llevar el runtime de JavaScript al backend.
    Incluso sin gestor de paquetes, en Windows es simplemente node.exe, y hasta donde sé basta con descargar y descomprimir npm, y poner node y npm en la variable de entorno PATH.
  • Toda la premisa de Rails 7 es precisamente eliminar la dependencia de node.
  • Nunca he usado Rails, así que tengo curiosidad: quisiera saber por qué “Ruby on Rails” necesita nodejs.
    Y la instalación de node es bastante fácil. De hecho, demasiado fácil. Ojalá fuera mucho más difícil y requiriera un título universitario.
  • La comunidad de Ruby/Rails es de las mejores y más amables que he visto. Pero lo peor de ella, por mucho, es el odio a JavaScript.
    JavaScript es solo una herramienta, como cualquier otra. Te guste o no, es una herramienta muy importante, y te guste o no, se va a quedar por mucho tiempo.
    Si tienes una mente un poco más abierta y aprendes al menos lo básico, el trabajo se te hará más fácil.

• Espero que haya un resurgimiento de Rails + HTMX y de la idea de espolvorear un poco de JavaScript solo en páginas con mucha interacción.
  Usar Rails con Slim/HAML es realmente agradable. Si quieres, también puedes usar librerías como ViewComponents para facilitar aún más el renderizado parcial. Si a eso le sumas web components, puedes construir páginas bastante interactivas, y si de verdad hace falta en una página específica, también puedes usar React.
  HATEOAS reduce mucho la complejidad de la aplicación. Aun así, si necesitas una API, también es muy fácil responder a distintos tipos MIME, e incluso puedes compartir el mismo endpoint si quieres.
  En mi experiencia, la mayoría de las aplicaciones que usan React en realidad no necesitan React para nada. Usan React por unos cuantos menús emergentes.
  Por eso, si empiezan a aparecer apps grandes sin React, o con muy poco React, espero que algunas personas se den cuenta de lo innecesariamente complejas que son nuestras aplicaciones hoy.
  Pero ya estoy viendo comentarios de “como todos usan React, tenemos que cambiarnos a React”. Me da un suspiro.
  Uno puede soñar.

• El anuncio oficial está aquí: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Hay un poco más de detalle de alto nivel, y me entusiasma probar algunos de los cambios nuevos. En particular, los nuevos métodos de consultas asíncronas parecen bastante útiles para obtener mejoras rápidas de rendimiento

• Rails en el backend no recibe todo el reconocimiento que merece
  Pero el lado del frontend fue un desastre durante muchísimo tiempo

  • No discrepo con que “el lado del frontend fue un desastre durante mucho tiempo”, pero el frontend en sí también fue un desastre durante mucho tiempo
    Ahora es un gusto trabajar con la combinación Rails 7.1 + Hotwired + Importmaps
    Pero hubo que esperar hasta que los navegadores tuvieran al menos buen soporte para ES6 e Import Maps
    Si miras la fecha de este artículo, https://web.dev/import-maps-in-all-modern-browsers/ anunció el 28 de marzo de 2023 que importmaps ya se podía usar en todos los navegadores modernos
    Así que hasta ahora no había forma de evitar Webpack, Yarn y otras herramientas auxiliares de JavaScript
    Ahora que tenemos importmaps y el soporte de ES6 en los navegadores ya es suficientemente bueno, https://caniuse.com/?search=es6, se puede usar JavaScript moderno casi sin herramientas adicionales
  • De acuerdo. ¿Cuáles serían las opciones aquí? ¿Rails en modo solo API?
  • Me gustan las nuevas funciones de Hotwire. Me pregunto qué no te gusta del frontend

• Hace unas semanas un amigo bromeó: “Si se anuncia un release de Rails y tú no abres un PR de upgrade, ¿realmente pasó?”
  Bueno, ahora toca abrir el PR. Aunque tenga que apilarlo detrás del PR de 7.0 que lleva meses esperando

• Según mi experiencia, a muchos equipos les cuesta crear una base de código limpia con ActiveRecord

• Espero que no me peguen, pero todavía uso Rails 4.2 y estoy contento
  Me da todo lo que necesito para trabajo SaaS backend sin JavaScript o con muy poco JavaScript, ya sea propio o para empresas B2B, y corre incluso en VPS de bajos recursos
  Si alguien tiene tiempo para responder, me da curiosidad saber por qué debería actualizar

  • Yo también uso una versión antigua. Primero habría que ver si puedes subir al último parche/versión menor
    El problema central de las versiones antiguas son las vulnerabilidades de las gemas vinculadas. Por ejemplo, quizá no puedas actualizar nokogiri sin un upgrade mayor de Rails
    Dicho eso, la mayoría de las apps no hacen, por ejemplo, parsing XML complejo, así que muchas de esas vulnerabilidades no aplican. Por eso hace falta algo de mantenimiento para verificar si estás seguro. También es común meter monkey patches para evitar bugs
    Actualizar mejora la seguridad y reduce el tiempo de mantenimiento. Pero también hay que considerar el costo de las actualizaciones constantes. Otro factor es que las versiones nuevas pueden darte soporte para versiones de Ruby más rápidas
    Normalmente, cuando creo una app Rails uso el release más reciente, pero después no subo de versión de Rails salvo que sea popular o que la app sea muy antigua y algo no funcione en sistemas nuevos
  • Deberías actualizar por seguridad