Un mantenedor de Hanami arranca una serie sobre en qué se diferencia de Rails

Un mantenedor del equipo Hanakai —el que está detrás de Hanami, dry-rb y ROM— ha empezado a publicar "Hanami, Why?", una serie de entradas en su blog para explicar en qué se diferencia Hanami del resto de frameworks web de Ruby y por qué, a su juicio, esas diferencias juegan a favor. La primera entrega no entra en materia: sirve de presentación de las piezas básicas del framework y deja el desarrollo para las siguientes.

Su propio sitio es la excusa y el banco de pruebas. Corre sobre Hanami y, por debajo, lleva publicación cruzada en Bluesky y Mastodon, un diario privado, un motor de analítica propio, un backend de mensajería para el formulario de contacto, un gestor de tareas que sincroniza con Linear y GitHub Issues y un feed de actividad que junta commits, entradas y tareas para responder a "qué hice entre tal y tal fecha". El código del sitio es abierto y está en GitHub.

Sobre el motivo del cambio: dice que Rails se le quedaba rígido y que pelearse por hacer las cosas de otra forma era la norma, hasta el punto de escribir aplicaciones web en Sinatra buscando más libertad. Había tocado las primeras versiones 1.x de Hanami, pero el encuentro serio fue en la RubyConf 2024 de Chicago. Hoy forma parte del equipo que mantiene el framework.

Cuatro abstracciones en vez de una

Lo que más choca a quien viene de Rails es el reparto de responsabilidades. Hanami empuja hacia abstracciones pequeñas y de un solo propósito, y de todas ellas destaca cuatro: Actions, Relations, Repos y Operations. Una Action es un endpoint HTTP; una Relation es la capa que consulta la base de datos; un Repo es una capa opcional por encima que agrupa una o varias relations y siempre devuelve structs, para que el objeto de persistencia no circule por la aplicación; y una Operation implementa el patrón comando sobre dry-operation y devuelve un objeto Success o Failure. Traducido: un CRUD sencillo acaba repartido entre cuatro clases.

Debajo hay más piezas de dry-rb. dry-system se encarga de la inyección de dependencias mediante el módulo Deps, que se incluye en la clase junto a la lista de lo que quiere inyectar. dry-types sostiene el sistema de tipos con el que valida y normaliza la entrada del usuario. dry-monads aporta los objetos Success y Failure, que combinados con pattern matching simplifican las mutaciones. El ejemplo que enseña es una acción que declara la forma de sus parámetros, los valida, responde 422 si no cuadran y delega en la operación CreateUser.

Queda por ver el resto. El autor plantea que Hanami puede escalar mejor que sus alternativas en según qué circunstancias, pero de momento es su tesis, no una comparativa: no hay cifras ni pruebas en la entrada. Las siguientes entregas de la serie son las que tienen que sostenerlo.