Chez Happy Scribe, nous avons une équipe de 6 ingénieurs produits qui construisent et entretiennent une application web qui sert 500 000 utilisateurs par mois. Un de nos outils secrets : Ruby on Rails.
Pour de nombreuses personnes dans le monde du web, Ruby on Rails est une chose du passé, mise de côté dans la maison de repos des frameworks web aux côtés de ASP.NET et JSP. Chez Happy Scribe cependant, nous sommes convaincus que Ruby on Rails a été et reste l'un des principaux contributeurs au succès de l'entreprise. Heureusement, nous ne sommes pas seuls. Un large éventail d'entreprises, grandes et petites, utilisent RoR pour servir des millions d'utilisateurs chaque jour. Shopify et GitHub sont les plus connus, qui contribuent également à la communauté en faisant avancer le framework et en faisant connaître pour amener plus de gens à bord.
La doctrine Rails décrit un ensemble de principes auxquels le framework essaie de se conformer. Pour nous, deux d'entre eux créent une combinaison gagnante qui garantit aux programmeurs de se concentrer sur ce qui compte et de ne pas perdre de temps à prendre des décisions qui peuvent être déléguées à quelqu'un d'autre :
Convention over Configuration: An example is Rails’ project and file structure. Every new project comes with a trusted MVC pattern. On top of that, it includes a default set of actions (index, show, update, delete, etc.) that cover most use-cases for any webapp. Just name the view and the controller function with the appropriate name and voilà, things just work.
Le menu est omakase: Il s'agit d'un ensemble de bibliothèques et de technologies que quiconque configure un nouveau projet Rails peut simplement installer sans avoir à descendre dans un terrier de lapin pour comparer les étoiles de GitHub et l'historique des validations pour évaluer différentes options. Pour chaque préoccupation de votre application, de la connexion à la base de données à l'envoi d'e-mails, il existe soit une bibliothèque par défaut livrée avec le framework, soit quelques-unes testées par la communauté. En conséquence, la plupart des applications Rails ont le même ensemble de bibliothèques et d'outils de base.
Grâce à eux, notre CTO Marc a réussi à construire la version initiale de Happy Scribe en moins de 2 semaines alors qu'il était encore à l'université et sans réelle expérience de la programmation. Ce même code a servi de solide fondation pour la croissance qui est survenue dans les mois suivants. Six ans plus tard, nous sommes heureux de dire que nous n'avons jamais eu à passer par la réécriture complète typique des startups nécessaire pour supporter la croissance exponentielle après avoir trouvé l'adéquation produit-marché. Nous sommes assez sûrs que le résultat aurait été différent si Marc avait choisi la pile MERN. Imaginez juste une application Express construite par quelqu'un qui n'avait pas appris toutes les meilleures pratiques d'un ingénieur senior dans une entreprise mature.
Travailler avec Ruby on Rails est une expérience agréable — la plupart du temps. Grâce à un minimum de boilerplate et au rendu côté serveur, la création d'un nouveau produit nécessite peu de temps. Aucun temps n'est perdu à décider quel payload envoyer au client et comment le stocker dans l'état pour le rendu. Les modèles, associés aux Turbo frames, couvrent 80 % des besoins du produit. En ce qui concerne la mise en œuvre des mises à jour en direct, Turbo Streams rend vraiment simple l'envoi de nouvelles IU directement depuis le serveur vers les clients qui en ont besoin. Enfin, pour les 10 % restants de réactivité côté client, Stimulus est là pour ajouter les pincées de JS nécessaires.
La simplicité de Rails signifie qu'à Happy Scribe, tous les ingénieurs sont full-stack. Cela nous permet de travailler sur des fonctionnalités complètes individuellement, en nous fournissant tout le contexte qui nous permet de prendre des décisions produit et techniques en ayant toutes les informations en tête. En fin de compte, notre temps en tant que développeurs est consacré aux tâches qui ajoutent de la valeur au produit, réduisant ainsi la quantité de lignes de code requises et en abstrayant la complexité, tout en s'amusant à être productif.
Enfin, un pouvoir sous-estimé de RoR est qu'il élimine les distractions tentantes auxquelles les ingénieurs aiment consacrer trop de temps. Dans le monde de JS, par exemple, toutes les deux semaines, il y a une nouvelle bibliothèque basée sur React promettant des temps de rendu plus rapides, ou un nouveau runtime côté serveur qui prétend surpasser NodeJS de manière significative. Dans l'écosystème Rails, nous pouvons rester concentrés, et tous nos « et si » peuvent être orientés vers la réflexion sur la manière de passer à la prochaine version majeure du framework.
L'espace de l'infrastructure n'a pas non plus réussi à échapper aux cycles de hype. Microservices, orchestration de conteneurs, multicloud, serverless, vous l'appelez. Seulement récemment, les gens ont commencé à se demander si ces technologies, conçues pour des organisations avec des milliers d'ingénieurs, avaient du sens dans leur entreprise. Notre application principale est un majestueux monolithe déployé sur Heroku. Nous sommes d'accord avec Daniel, “Les microservices étaient un phénomène à 0% d'intérêt”.
Beaucoup de gens pensent que Ruby est lent et ne s'adapte pas. Nous pourrions écrire mille mots sur le fait que ce n'est pas le cas (jetez un œil au nouveau compilateur YJIT) mais à la place, nous dirons simplement que Happy Scribe dépense 1 000 €/mois sur des serveurs web Heroku, ce qui représente environ 0,2 % de notre chiffre d'affaires. Nous pourrions réduire cela d'un ordre de grandeur si nous migrions vers un fournisseur de cloud moins cher comme Hetzner, ce que nous avons fait pour notre infrastructure de traitement des médias.
Nous devons être honnêtes avec nous-mêmes, ce n'est plus l'âge d'or de Rails, bien que cela puisse changer dans les années à venir. Les étudiants n'apprennent pas Ruby on Rails pendant leur temps libre, ni les bootcamps ne l'enseignent. En 2024, JavaScript et toutes ses différentes variantes règnent en maître. Selon la dernière enquête des développeurs de Stack Overflow, environ 40 % des répondants ont sélectionné Node.js et/ou React comme leurs technologies de prédilection, contre seulement 5 % qui ont choisi Ruby on Rails.
Ces statistiques sont assez décourageantes pour quiconque essaie d'embaucher des ingénieurs RoR en 2024. Cependant, il y a de bonnes nouvelles : RoR peut être appris, et vraiment rapidement! Il n'est pas nécessaire d'avoir des connaissances préalables en RoR comme exigence essentielle dans nos offres d'emploi. Voici plus : aucun des ingénieurs qui ont travaillé chez Happy Scribe ne connaissait RoR avant de rejoindre l'entreprise. Malgré cela, ils sont tous devenus productifs très rapidement, apportant leur première contribution à la production en quelques jours seulement. En 3 à 6 mois, ils sont totalement immergés dans la mentalité Rails et écrivent un code complexe et idiomatique.
Il est indéniable que Ruby on Rails est un framework web complet, donc les applications y sont fortement liées. Même si quelqu'un voulait s'éloigner de Rails, il n'y a vraiment aucune alternative pour lui dans l'écosystème Ruby. En fin de compte, la vérité est que une fois que vous commencez avec RoR, vous êtes un peu marié à vie, mais nous acceptons cette contrainte.
Non seulement cela, nous rejetons consciemment une architecture pure Hexagonale. Le fait que nous pourrions construire la même application en Django ne signifie pas que nous allons le faire. Il est très probable que nous restions avec Rails pour toujours. Nous n'avons pas besoin d'abstraire complètement Rails au cas où nous migrerions. Si nous le faisions, nous perdions la plupart des avantages de son utilisation. Nous nous accouplons fortement et fièrement avec Rails.
Enfin, il convient de mentionner que ces dernières années, le framework RoR et sa communauté ont commencé à connaître une renaissance. Le framework progresse à une vitesse sans précédent, en suivant les fondamentaux du web moderne et en les adaptant à l'esprit Rails. Hotwired est un exemple clair de deux nouvelles technologies, Turbo et Stimulus, utilisées pour intégrer directement dans le cœur du framework l'interactivité que les utilisateurs attendent. Ces avancées nous donnent encore plus de raisons de croire que le framework continuera de répondre à nos besoins et à ceux de nos utilisateurs à l'avenir.
Chez Happy Scribe, Ruby on Rails est bien plus qu'un simple framework, c'est un partenaire stratégique dans notre parcours de croissance et d'innovation. Son mélange de convention, de productivité et de stabilité en fait un atout inestimable dans notre pile technologique, et nous voyons qu'il restera ainsi pour les années à venir.
Vous envisagez de sortir du cloud pour réaliser des économies de coûts tout en hésitant à renforcer une équipe opérationnelle ? Nous avons opté pour une étape intermédiaire qui nous a permis d'économiser la majorité de nos coûts sans ajouter beaucoup de frais opérationnels.
Chez Happy Scribe, nous avons une équipe de 6 ingénieurs produits qui construisent et entretiennent une application web qui sert 500 000 utilisateurs par mois. Un de nos outils secrets : Ruby on Rails.
