Rails es un framework compatible con Rack centrado en el desarrollo rápido de aplicaciones. Desafortunadamente, el enfoque de "todo fuera de la caja" y el comportamiento ciego Rails-way a menudo hacen que el código de la aplicación pierda calidad, tanto en términos de su recepción (legibilidad) como de funcionamiento.
Problemas populares de Rails y Rails-way
- enrutamiento,
- acciones previas,
- grandes acciones en los controladores,
- métodos privados en los controladores,
- mixins utilizados una vez,
- lógica en las vistas,
- Devoluciones de llamada de ActiveRecord,
- Asociaciones,
- "modelos gordos".
Problemas adicionales
- Validaciones de registros activos,
- implícita sobre explícita,
- abuso de DRY,
- delegaciones en las asociaciones,
- llamadas de servicio en los modelos.
Alternativas a Rails
Cuando se trata de Rieles en el Ruby mundo, tenemos varias alternativas. Otros frameworks basados en Rack son: - Sinatra, – Roda, – Hanami.
¿Qué los hace únicos?
Tanto Sinatra como Roda nos ofrecen una sintaxis de enrutamiento por bloques, pero el enrutamiento en Sinatra es una lista y en Roda - un árbol. En ambos frameworks, tenemos que ocuparnos nosotros mismos de la implementación de la capa del modelo. En el caso de Roda, es una buena idea utilizar la gema Sequel.
Roda está inspirado en Sinatra. Es muy ligero en sí mismo, pero tiene un montón de plugins.
Hanami es lo más cercano a Rieles en lo que respecta a los ámbitos cubiertos por el marco. Las diferencias más importantes en términos de uso son:
- controladores en Rieles frente a las acciones en Hanami,
- clases / objetos dedicados a gestionar una solicitud HTTP específica, no un controlador para acciones relacionadas con un recurso específico (modelo),
- capa de modelo basada en repositorios y entidades, separando la persistencia del resto de la aplicación, no el patrón de registro activo.
Hanami versión 1 limita fuertemente el uso de ROM se basa en (versión 3, y ya es 5), por lo que no vale la pena utilizar la capa de modelo propuesto allí. Sin embargo, como es un framework muy abierto, es bastante fácil implementar allí el modelo propio.
Suplementos para Rails
Merece la pena utilizar soluciones que no dependan de Rieles y se acercan más a lo "puro" Ruby. Las herramientas mencionadas en la presentación son:
- Sequel (ORM, alternativa a ActiveRecord),
- ROM (mapeador de objetos),
- bibliotecas dry-rb: dry-validations, dry-system y dry-monads.
La secuela es fácil de poner en un proyectoEl sistema se basa en plugins y también implementa el patrón de registro activo. Tiene mejor soporte de consultas de bajo nivel que Rieles' ActiveRecord.
ROM utiliza Sequel, pero su concepto es traducir entre registros de la(s) base(s) de datos y Ruby objetos. Busca la velocidad y la transformación de datos. Separa claramente la capa de persistencia en la aplicación.
Las bibliotecas Dry-rb son herramientas muy útiles:
- La validación en seco es muy fácil de utilizar en proyectos de API y permite un gran control sobre la corrección de los datos entrantes,
- dry-system necesita un poco de pratcice y paciencia para que los desarrolladores lo entiendan, pero permite una gestión muy flexible de las dependencias en la aplicación y la carga de componentes del proyecto de forma aislada; si queremos utilizar esta biblioteca en Rielespodemos utilizar raíles secos,
- mónadas secas es un concepto difícil en teoría, pero en la práctica es más fácil de entender, el resultado mónadas puede ser una gran manera de aumentar la legibilidad de código considerando casos específicos en lugar de ramificaciones if.
Conclusiones
Lo mejor es utilizar Rieles para no tener que utilizar Rieles un día.
Fuentes
Artículos
Marcos
Gemas
Especificaciones
Más información:
¿Qué es Ruby on Jets y cómo crear una aplicación con él?
Vuelendar. Un nuevo proyecto de Codest basado en Vue.js
Informe semanal de Codest sobre los mejores artículos tecnológicos. Creación de software para 50 millones de sockets simultáneos (10)