Recap de “Dreaming Bigger with Rails 2022”

Avec plus de 250 participants, “Dreaming Bigger with Rails” a confirmé son statut parmi les événements qui comptent le plus dans la sphère Rails française. 

WizVille organisait cet évènement pour la 2ème année consécutive avec pour objectif de permettre à l’écosystème d’apprendre des meilleurs, pour faire de 2022 une année encore plus belle que 2021. 

Pour cela, nous avons réuni certains des acteurs et penseurs les plus intéressants du monde Rails, afin de s’inspirer et de relever au mieux les défis techniques qui se présentent à nous en 2022, au premier lieu desquels le lancement d’algorithmes de recommandations basés sur l’analyse croisée à grande échelle d’avis clients et de données tierces qui visent à réinventer le management de la satisfaction client en entreprise. 

Le 2ème objectif pour nous : faire savoir que WizVille a les moyens de ses (grandes) ambitions et que c’est le moment de nous rejoindre ! Nous projetons en effet de doubler nos effectifs en 2022 et recrutons en permanence des Développeurs Seniors. 

Quelques chiffres

Pour illustrer le succès de “DBR” 2022, autant sur le fond que sur la forme, quelques chiffres qui parlent d’eux-mêmes : 

• 260 attendees
• 2h20 de talks
• 10 speakers, 
• 6 CTO ou équivalent parmi les speakers
• 6 startups (SaaS, Gaming & Ecommerce)
• 2 licornes

Bonus : et 7 memes … mémorables ! 

Panel 1 : Le “Fireside Chat” avec DHH 

Lors de ce Fireside Chat avec David Heinemier Hansson, créateur de Ruby on Rails, co-founder de Basecamp, et NYT best selling author, qui nous honorait de sa présence pour la 2ème année consécutive, il a principalement été question d’Hotwire, mais aussi des évolutions technologiques les plus marquantes de 2021. 

“Lead the revolution against Node”

Comme à son habitude DHH n’a pas caché son animosité vis-à-vis de l’utilisation massive de javascript dans le développement web moderne, estimant que cela rajoute une couche de complexité qui ralentit inutilement les équipes depuis quelques années.

Plutôt que d’envoyer de la donnée en JSON depuis une API qui servira ensuite à hydrater un composant React ou autre, DHH nous propose une approche alternative, Hotwire, dans laquelle ce sont des fragments de page en HTML qui sont envoyés depuis le serveur.

“People have hit enough walls with the traditional javascript framework”

DHH défend l’idée que l’organisation “équipe frontend” / “équipe backend” est un luxe de très grosses entreprises et que pour la plupart des cas une approche fullstack avec Hotwire est largement suffisante.

À titre d’exemple le client mail Hey a été développé en Hotwire avec seulement 30Ko de javascript compressé alors que pour un Gmail ce chiffre monte à 4.8mo !

“Bundlers / transpillers are a regression, not a revolution”

DHH nous a également partagé son engouement concernant le support natif des modules  / import maps sur chrome (https://chromestatus.com/feature/5315286962012160), permettant de se diriger petit à petit vers un monde sans bundler, responsable d’un bon morceau de la complexité du développement web actuel. En effet cette évolution permet de charger dynamiquement du code javascript (via import) mais sans avoir besoin d’un bundler type webpack, donc gain de temps en bundling et plus besoin de se lancer dans les configurations souvent capricieuses de webpack ou autre.

Regardez le replay de cet échange avec David Heinemeier Hansson (DHH)

Panel  2: "Take your Tech Stack to the Next Level", avec Sorare,  Doctolib & WizVille

Une table ronde entre Nicolas Denayer, VP Engineering chez Doctolib, Sylvain Utard, Head of Engineering de Sorare et Clément Bruchon, CTO de WizVille a mis en évidence une fois de plus que le premier goulot d’étranglement d’une app web, c’est la base de données. Ruby n’est probablement pas le langage le plus rapide qui existe, mais la vraie bataille de la performance d’une app web ne réside pas là.

Le panel a également pu échanger autour de nouveautés sur l'écosystème Rails.

Gestion des requêtes asynchrones depuis rails 7

L’absence de concurrence est fréquemment reprochée à ruby, c’est d’ailleurs en partie ce qui a propulsé NodeJS sur le devant de la scène.

Dans le cadre d’une app web, on veut en gros exécuter de façon concurrente 2 choses : des calls API externes et des requêtes aux bases de données.

Et bien Rails 7 règle la partie base de données grâce à l’ajout de load_async qui permet d’exécuter une requête active_record dans un thread (https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision).

📓 Documentation Load_Async

Gestion des Read Replicas depuis Rails 6

Gérer proprement les Read Replicas en rails n’a jamais été chose facile, il y a bien eu quelques tentatives, par exemple la gem octopus mais peut d’équipes ont pris le risque d’utiliser ce genre de gem dans un environnement aussi délicat que la production.

Depuis Rails 6 cette gestion est native, c'est-à-dire que vous pouvez dire à Active Record d’utiliser une base de données précise en lecture et une autre en écriture

Particulièrement utile dans un contexte de bases de données off-loadées, même s’il faut tout de même se méfier des quelques secondes de latences qu’il peut y avoir entre un read replica et le master en écriture.

📓 Documentation Read Replicas sur Active Record

Gem interactor 

Solution intéressante pour se sortir élégamment des problèmes de callback hell, interactor permet de chaîner les actions qui composent un workflow métier, passant à chaque fois le retour de l’étape précédente à l’étape suivante.

Chez Sorare ils ont poussé le concept jusqu’à gérer les workflows asynchrones, ils vont potentiellement open sourcer la chose, affaire à suivre.

📓 Documentation de la gem Interactor sur GitHub

Gem Hinter 

Très pratique lorsqu’il s’agit de comprendre pourquoi un bloc de code ruby est lent, hinter (projet porté par WizVille et en particulier par notre CTO, Clément Bruchon) permet de comprendre ligne par ligne le nombre de requêtes générées par active record, le temps passé en exécution ruby et le temps passé en exécution active record.

Contrairement aux technologies de monitoring classique (sentry, datadog, …) qui se concentrent sur de l’analyse page par page, Hinter fonctionne dans un contexte de console ou de debugger et résonne en termes de ligne de code.

Cela s’avère particulièrement utile lorsqu’on est face à un workflow composé de plusieurs actions successives et qu’on l’on veut comprendre la consommation en temps et en requêtes de chaque action, ligne par ligne.

Imaginons que l’on cherche à analyser le bloc de code suivant : 

Hinter va pouvoir l’instrumenter de la manière suivante:

Ce qui produira l’analyse suivante :

On apprend donc que les lignes 1 et 3 génèrent 1 requête chacune, que les lignes 2 et 4 sont négligeables en termes de consommation de performance, et que le traitement ruby de la ligne 3 est plus lourd. En conclusion s'il y a des efforts d’optimisation à faire il faudra s’intéresser à la ligne 3 en priorité. Pratique également pour détecter les N+1 du coup : )

📓 Documentation de la  gem Hinter sur Github

Replay de ce panel : 

Panel 3 : "Hotwire Developers Share their Journeys from 0 to 1" 

Pour conclure ce Dreaming Bigger With Rails 2022, Adrien Siami de Ecotable, Adrien Poly de Plume et Bob Maerten de Home Ciné Solutions, nous ont présenté des projets sur lesquels ils utilisent Hotwire.

Adrien Siami a commencé par nous faire une démonstration de la puissance des turbo streams, brique de turbo ajoutant la possibilité de modifier le dom d’une page après une action, une validation de formulaire qui met à jour un compteur par exemple.

Adrien Poly nous a ensuite montré l’utilisation des frames turbo dans une modale, permettant de scoper la navigation dans un élément du dom, sans pour autant avoir les restrictions historiques inhérentes aux iframes.

Et pour terminer Bob Maerten nous a montré comment rendre facilement un formulaire dynamique grâce à Stimulus. C’est une bonne alternative à l’import de librairies UI lourdes uniquement pour de la validation de formulaire ou de simples animations.

Pour conclure Hotwire se place clairement dans la niche du “one man framework”, offrant une alternative sérieuse à la stack classique react / api pour les équipes réduites. Cependant, le fait d’utiliser du HTML dans les requêtes ne laisse pas beaucoup de possibilités pour s’intégrer avec du mobile, imposant l’utilisation de webviews, pas forcément génial si on veut utiliser la charte graphique du device. Mais bien sûr tout le monde n’a pas ce genre de besoin, et nous ne doutons pas que le gain de vélocité offert par la simplicité de Hotwire va séduire plus d’une équipe à l’avenir.

Replay du panel Hotwire :

Des memes… mémorables ! 

“DBR” fait désormais partie des évènements les plus attendus de l’année par l’équipe WizVille, qui s’en donne à coeur joie chaque année niveau memes :-) 

Voici une collection des memes les plus mémorables de cette année, enjoy : 

Remerciements

Un grand merci à tous les participants, qui ont suivi avec attention cet évènement, et ont fait le succès de cette édition 2022 ! 

Un grand merci également à nos incroyables speakers, qui ont eu le courage de partager leurs réussites, leurs challenges et fait avancer tout l’écosystème par la richesse de leurs témoignages. Un merci tout particulier à Adrien Siami CTO d’Ecotable qui a participé à l’organisation de cet évènement et leadé la sélection des développeurs Hotwire les plus intéressants de France.