Rails est un framework compatible avec Rack, axé sur le développement rapide d'applications. Malheureusement, l'approche "everything out of the box" et le comportement aveugle de Rails-way entraînent souvent une perte de qualité du code de l'application, tant au niveau de sa réception (lisibilité) que de son fonctionnement.
Problèmes populaires liés à Rails et à Rails-way
- routage,
- avant les actions,
- des actions d'envergure au niveau des contrôleurs,
- les méthodes privées dans les contrôleurs,
- mixins utilisés une seule fois,
- logique dans les vues,
- Rappels ActiveRecord,
- Associations,
- "gros modèles".
Problèmes supplémentaires
- Validations des enregistrements actifs,
- implicite plutôt qu'explicite,
- abuser de DRY,
- les délégations aux associations,
- les appels de service dans les modèles.
Alternatives à Rails
Lorsqu'il s'agit de Rails dans le Rubis nous disposons de plusieurs alternatives. D'autres frameworks basés sur Rack incluent : - Sinatra, – Roda, – Hanami.
Qu'est-ce qui les rend uniques ?
Sinatra et Roda nous offrent tous deux une syntaxe de routage par bloc, mais le routage dans Sinatra est une liste et dans Roda - un arbre. Dans les deux frameworks, nous devons nous occuper nous-mêmes de l'implémentation de la couche de modèle. Dans le cas de Roda, c'est une bonne idée d'utiliser la gemme Sequel.
Roda est inspiré de Sinatra. Il est très léger en soi, mais il possède de nombreux plugins.
Hanami est le plus proche de Rails en ce qui concerne les domaines couverts par le cadre. Les différences les plus importantes en termes d'utilisation sont les suivantes :
- contrôleurs en Rails vs. actions dans Hanami,
- des classes/objets dédiés au traitement d'une requête HTTP spécifique, et non un contrôleur pour les actions liées à une ressource spécifique (modèle),
- basée sur des référentiels et des entités, séparant la persistance du reste de l'application, et non sur le modèle de l'enregistrement actif.
Hanami version 1 limite fortement l'utilisation de la ROM sur laquelle il est basé (version 3, et il est déjà 5), il n'est donc pas intéressant d'utiliser la couche de modèle qui y est proposée. Cependant, comme il s'agit d'un framework très ouvert, il est assez facile d'y implémenter son propre modèle.
Suppléments pour Rails
Il est intéressant d'utiliser des solutions qui ne dépendent pas des Rails et sont plus proches de la "pureté" Rubis. Les outils mentionnés dans la présentation sont les suivants :
- Sequel (ORM, alternative à ActiveRecord),
- ROM (object mapper),
- bibliothèques dry-rb : dry-validations, dry-system et dry-monads.
La suite est facile à mettre dans un projetIl est basé sur des plugins et met également en œuvre le modèle d'enregistrement actif. Il offre une meilleure prise en charge des requêtes de bas niveau que Rails' ActiveRecord.
ROM utilise Sequel, mais son concept consiste à traduire les enregistrements de la (des) base(s) de données en enregistrements de la Rubis objets. Il vise la rapidité et la transformation des données. Il sépare clairement la couche de persistance de l'application.
Les bibliothèques Dry-rb sont des outils très utiles :
- dry-validation est très facile à utiliser dans les projets d'API et permet de contrôler l'exactitude des données entrantes,
- dry-system nécessite un peu de pratique et de patience pour que les développeurs le comprennent, mais il permet une gestion très souple des dépendances dans l'application et le chargement des composants du projet de manière isolée ; si nous voulons utiliser cette bibliothèque en RailsNous pouvons utiliser des rails secs,
- Les monades sèches sont un concept difficile en théorie, mais en pratique il est plus facile à comprendre, le résultat des monades peut être un excellent moyen d'améliorer la lisibilité de l'information. code en envisageant des cas spécifiques plutôt que des "si" ramifiés.
Conclusions
Il est préférable d'utiliser Rails de sorte que vous n'ayez pas à utiliser Rails un jour.
Sources d'information
Articles
Cadres
Pierres précieuses
Spécifications
En savoir plus :
Qu'est-ce que Ruby on Jets et comment construire une application en l'utilisant ?
Vuelendar. Un nouveau projet de Codest basé sur Vue.js
Le rapport hebdomadaire de Codest sur les meilleurs articles technologiques. Construire un logiciel pour 50 millions de sockets simultanés (10)