Ruby on Rails en 2018

Article écrit par Quentin Buirette

Vous me voyez sans doute venir…

Utiliser Ruby on Rails en 2018 ? Et puis quoi encore ?

Ruby on Rails est un bon et un mauvais framework pour de nombreuses raisons. Qu’en est-il de ce choix technologique aujourd’hui ?

C’est justement ce que nous allons découvrir !

Rails et ses inconvénients

Un langage peu performant

Comme vous le savez parfaitement, Ruby on Rails se base sur le langage Ruby, qui n’est pas si vieux puisqu’il n’a que 25 ans.

Malgré sa jeunesse vigoureuse, Ruby souffre de quelques défauts compensés par un objectif précis : en faire un langage cool !

Ruby n’a pas toujours eu bonne presse auprès des différents acteurs de l’IT. Le principal argument ? Les performances de Ruby ne sont pas dignes d’un bon langage pour développer des applications.

Il est vrai qu’on ne penserait pas forcément à Ruby pour faire du système embarqué, Il suffit de taper les trois termes embedded, system et ruby dans une recherche sur Github pour s’en rendre compte.

Mais il n’en est pas moins largement suffisant pour une application complexe ; sans compter qu’il existe une multitude de projets importants qui utilisent Ruby on Rails comme Redmine, Basecamp, Github, Airbnb ou encore Kickstarter, pour ne citer qu’eux.

Par ailleurs, la core team annonce un gain de performance important pour la version 3 de Ruby.

On peut alors espérer un regain d’intérêt pour ce langage.

Comme l’a dit un jour le créateur de Ruby, le dénommé « Matz », de son vrai nom Yukihiro Matsumoto :

Ruby est simple en apparence, mais son architecture interne est très complexe — tout comme notre corps peut l’être.

De la magie abracadabrantesque

C’est bien connu, pour la plupart de ses détracteurs, Ruby on Rails est un framework pensé pour les magiciens sans talent…

Un problème, un monkey patch et le tour est joué !

C’est un fait, déroutant, ambigu, pas très propre, mais concret.

Bien que plaisant, le DSL de Rails peut parfois être obscur. Par ailleurs, il se distingue partiellement de celui de Ruby et peut entraîner des incompréhensions entre le framework et le langage. C’est pourquoi il est important de faire la distinction entre les deux.

Si vous n’êtes pas d’accord avec ça, alors venez tester vos connaissances avec ce quiz Ruby ou Rails !

D’expérience personnelle, il vaut mieux commencer par les bases de Ruby lorsqu’on s’intéresse à Rails. Ayant commencé par le framework sans connaître le langage et sans notion de magie quelconque, j’ai eu quelques difficultés à m’y retrouver.

Une application peut vite devenir un monstre difficile à maîtriser si les règles ne sont pas correctement établies dès l’origine du projet

Ruby on Rails nous permet notamment de concevoir des applications monolithiques.

Une application monolithique peut servir un dessein et peut parfaitement répondre aux besoins des utilisateurs. Toutefois, ce terme possède une connotation négative, puisqu’on imagine souvent un code difficile à maintenir ou à faire évoluer.

Par monolithique, on entend également ce qui se présente sous l’aspect d’un tout cohérent, sans contradiction (définition Larousse).

C’est assez vrai en réalité. La plupart des projets Rails vont avoir des contrôleurs à rallonge, sans parler des modèles qui contiennent toute la logique de validation, de persistance des données et de métier, ce qui n’est jamais une bonne chose…

Et ne parlons même pas de la logique métier présente directement dans la vue, puisque là aussi Rails nous permet de faire ce genre d’hérésie…

Je suis sûr que vous en avez plein d’autres…

On trouve aisément des points négatifs dans l’utilisation quotidienne de nos langages, frameworks, outils… Ce peut être intéressant de les lister afin de s’en faire une meilleure opinion sur le long terme.

Néanmoins, s’acharner à stigmatiser certaines technologies me paraît contre-productif.

Avec toutes les possibilités qui nous sont offertes en 2018, il nous appartient de creuser davantage afin d’affiner nos choix technologiques en fonction des projets sur lesquels nous travaillerons demain.

Rails possède quelques avantages significatifs

Simple à prendre en main

On peut lui reprocher beaucoup de choses, mais j’apprécie particulièrement Rails pour sa prise en main.

Nul besoin d’allouer un temps considérable à la formation pour commencer à faire du Ruby on Rails.

Poser les bases d’une nouvelle application n’a jamais été aussi simple

Ruby on Rails est l’un des premiers framework pensé par des développeurs, pour les développeurs. C’est la raison pour laquelle il est devenu si simple à utiliser.

Voici un setup basique pour lancer une nouvelle application :

# Requirement  Install Ruby Install Rails 

$ rails new my_project  $ rake db:create  $ bin/rails generate scaffold HighScore game:string score:integer   invoke  active_record   create    db/migrate/20130717151933_create_high_scores.rb   create    app/models/high_score.rb   invoke    test_unit   create      test/models/high_score_test.rb   create      test/fixtures/high_scores.yml   invoke  resource_route    route    resources :high_scores   invoke  scaffold_controller   create    app/controllers/high_scores_controller.rb   …  $ rake db:migrate  $ rails server 

Ensuite, il suffit d’ouvrir son navigateur préféré pour découvrir les rudiments de son projet.

Par cet exemple, nous venons de voir à quel point il est facile de réaliser des bases d’application web. C’est pourquoi Ruby on Rails se prête particulièrement à la réalisation de POC !

Rails est modulaire

Il est possible de ne charger que les composants dont vous avez besoin pour votre application.

On peut par exemple se passer de l’ORM Active Record, en choisir un autre ou encore écrire ses propres requêtes SQL.

Pour ce faire, rendez-vous dans le fichier de configuration suivant :

# config/application.rb  # Retirer cette ligne et charger uniquement les composants nécessaires require 'rails/all'  # Exemple : require "action_controller/railtie" require "action_mailer/railtie" 

Convention over configuration

C’est l’un des principes de base de Ruby on Rails !

Si cet état de fait peut paraître assez rigide, c’est justement l’idée inverse qui motive ce choix.

Il s’agit simplement d’appliquer des configurations de la même manière d’un projet à un autre.

L’idée est donc d’alléger la charge de travail du développeur en lui permettant de se focaliser sur les aspects métiers du projet, l’essentiel.

N’en déplaise à certains, la logique derrière l’utilisation de Gem est tout de même formidable, tout comme le versioning de migration de base de données avec Active Record !

Ruby

C’est fait en Ruby, donc c’est forcément bien !

Mine de rien, Ruby est un chouette langage (point de vue totalement subjectif), puisqu’il est simple et agréable à lire. De ce fait il est aussi plus simple de comprendre et de maintenir du code en Ruby.

Il faut toutefois considérer la qualité du code. On peut faire du Ruby parfaitement immonde ! Mais l’on retrouvera souvent une lecture du code relativement abordable.

Ruby on Rails est aussi moins rigide que la plupart des frameworks

Rails est un framework très flexible, voire un peu trop permissif. Serait-ce là l’un de ses plus gros défauts ?

Toutefois, sa souplesse permet à quiconque de poser rapidement les bases d’une application fonctionnelle. Elle permet facilement de mettre en place plusieurs langues sur son application grâce à I18n. Elle permet également d’implémenter de nouveaux composants via l’emploi de Gem, sans oublier un principe de base : DRY.

On constate néanmoins les limites dès que l’on souhaite concevoir une application monolithique qui soit (ou qui reste) maintenable avec Rails. Peut-être nous est-il nécessaire d’acquérir une approche différente, en pliant le framework à nos propres exigences par exemple.

Si ce sujet des applications monolithiques vous intéresse, je vous suggère cet article très intéressant sur l’architecture monolithique modulaire.

S’engager en réfléchissant préalablement à l’implémentation de la logique métier nécessite un effort supplémentaire dès l’origine d’un projet.

Néanmoins, cet effort peut se révéler payant à travers l’emploi de Ruby on Rails. Sa souplesse et sa simplicité permettent d’être agile, et d’ajouter rapidement de nouveaux composants à nos applications.

Reste à s’entendre sur une implémentation qui ne doit pas seulement convenir aux développeurs, mais qui se doit de respecter le vocabulaire et les attentes du métier.

De bons réflexes sont la clé du succès, et l’emploi de Rails nous autorise à prendre le temps de les remettre en question.

Outre ces aspects, pourquoi utiliser Rails en 2018 ?

Si l’on fait l’effort de prendre un peu de recul, on peut en déduire les affirmations suivantes concernant ce framework :

• Il convient bien aux étudiants en informatique qui doivent concevoir rapidement des applications s’ils ne sont pas contraints par un langage (j’en parle en connaissance de cause) ;
• Il convient parfaitement pour réaliser des POCs ;
• Rails 5 permet notamment de créer rapidement une API ;
• Il convient à la conception d’application web, dès lors qu’on fait l’effort de mettre en place des fondations solides. (cf. Pérégrinations vers une architecture découplée)

Qu’est-ce qu’il se passe ailleurs dans l’écosystème Ruby ?

Pendant ce temps, d’autres framework émergent, innovent, subsistent et gravitent autour de la planète Ruby.

Pour ne citer que les deux dont j’ai connaissance :

• Sinatra : parfait pour réaliser de simples CRUD, pour un site lambda sans grande logique métier
• Hanami : Si vous avez une volonté inébranlable d’architecturer vos applications, alors ce framework est fait pour vous

Pour aller plus loin, voici un top 10 des meilleurs frameworks Ruby.

Suite aux conversations avec le collègue de bureau qui ne jure que par ça, j’adresse une mention spéciale à Crystal. N’hésitez surtout pas à découvrir ce projet, car le potentiel est très prometteur. Gestion de la concurrence, performances importantes, mais surtout cette volonté d’intégrer le Multithread… Que du bonheur !

Retour à la terre ferme

Ruby on Rails n’a pas dit son dernier mot !

Certes, les choix récents vers plus de flexibilité et davantage de conception monolithique semblent un peu trop… trop… pour beaucoup d’entre nous.

Mais il n’en reste pas moins un framework très agréable à utiliser au quotidien.

En réalité, si l’on voulait vraiment conclure, on ne parlerait pas seulement de Ruby on Rails, mais de l’ensemble des frameworks que l’on peut trouver sur le marché.

Il nous appartient, et nous appartiendra encore demain, de se poser les bonnes questions :

• Avons-nous réellement besoin d’une usine à gaz pour notre projet ?
• Combien devrions-nous allouer de temps à notre veille technologique ?
• Possédons-nous les ressources nécessaires pour maintenir un projet dans cette technologie ?
• Ce framework est-il adapté à ce projet ?
• Avons-nous seulement besoin d’un framework pour ce projet ?
• etc.

Finalement, il importe que chaque framework possède ses propres forces et faiblesses. Puisque chaque projet nécessite une attention particulière, on devrait toujours s’interroger sur la pertinence de l’utilisation d’un framework avant de l’adopter.

La question n’est donc plus de savoir si Ruby on Rails est encore populaire aujourd’hui, mais plutôt de s’intéresser à la manière de mettre nos projets sur les rails.