Localtower v2: Il n'est jamais trop tard

English version of this post here (EN)
Spanish version of this post here (ES)
French version of this post here (FR)

Genèse de l’idée

En mars 2017, j’enseignais Ruby et Rails à des développeurs juniors. La façon naturelle d’apprendre Rails est de créer une application à partir de zéro, en ajoutant des modèles, des contrôleurs, des vues, etc. Un exercice simple pour comprendre comment les choses sont connectées.

Rails dispose d’outils fantastiques avec les migrations de base de données lorsqu’il s’agit de créer des modèles ou des migrations. L’API vous permet de gérer votre schéma de base de données comme un charme.

Et avec plus de 12 ans d’expérience avec Rails, je fais encore très souvent des erreurs.

La création d’une migration pour ajouter une nouvelle table est sujette aux erreurs. Il est facile de faire des erreurs ou des fautes de frappe dans le fichier généré lors de l’ajout de colonnes. Je reviens toujours à d’autres migrations, je copie la ligne qui ressemble à ce que je veux, j’adapte les noms et j’exécute rails db:migrate. Si j’ai une erreur, je retourne au fichier de migration, je consulte la documentation Rails si nécessaire, je le modifie et j’exécute à nouveau db:migrate.

Je voulais quelque chose de plus convivial : Une interface utilisateur claire avec des boutons et des menus déroulants pour créer des modèles et des migrations.

J’ai donc créé la première version de Localtower comme preuve de concept en quelques jours. Étonnamment, deux semaines après la sortie, elle a été présentée dans Ruby Weekly (numéro #341) et les téléchargements ont grimpé à plus de 38 870 téléchargements et 402 étoiles sur Github. (les statistiques sont ici sur BestGems.org)

C’était suffisant pour me convaincre de maintenir ce projet en vie. Non seulement comme outil pour faire de meilleures migrations, mais aussi comme outil d’apprentissage pour les développeurs juniors afin qu’ils comprennent toutes les possibilités qu’ils ont avec les migrations.

L’essor des outils de développement

Les choses ont beaucoup évolué depuis 2017 en matière d’outils de développement. Même si j’utilise Rails tous les jours et que je l’adore, tout le monde n’est pas à l’aise pour coder quand il s’agit de créer des prototypes. C’est pourquoi les outils low-code ou no-code sont devenus populaires. Pour une bonne raison :

Leurs interfaces utilisateur sont vraiment géniales.

Pour n’en citer que quelques-uns : Make, Zapier, Supabase, BuildShip, Bubble.

C’est pourquoi j’ai décidé de réécrire complètement l’interface utilisateur de Localtower et d’offrir une meilleure expérience aux développeurs en matière de gestion de base de données. La capacité d’itérer rapidement sur votre schéma SQL est essentielle pour le prototypage et même plus tard lorsque votre application commence à avoir plus de 10 tables.

Différences entre v1 et v2

Tout a changé entre v1 et v2 concernant l’interface utilisateur. Tous les composants backend principaux sont les mêmes (avec une petite refactorisation) mais l’interface est totalement nouvelle.

Toute la documentation se trouve sur le dépôt Github de Localtower : https://github.com/damln/localtower

Démo complète (2min)

Quelques captures d’écran

Contraintes techniques avec Rails Engine

Comme Localtower est un Rails Engine, il vit à l’intérieur d’une application Rails existante. Vous ne contrôlez pas l’application parente. Certaines personnes peuvent utiliser Localtower avec Rails 5.2, Rails 6, Rails 7 ou Rails 8. Cela signifie que vous ne pouvez pas utiliser les dernières fonctionnalités de Rails comme Turbo ou Streams car l’application parente pourrait utiliser une ancienne version de Rails. Plus important encore : le moteur ne peut pas définir sa propre version de Rails. Vous êtes complètement lié à la version de l’application Rails qui héberge le moteur.

Cela signifie que j’ai fini par faire des choses bizarres. Le pipeline d’assets devait être entièrement en javascript et ne pas s’appuyer sur sprockets ou propshaft afin d’être pérenne. Et les composants backend devaient prendre en charge différentes versions de Rails. Le côté backend était plus facile à gérer puisque j’utilise uniquement l’API de migration native.

ReactJS entre dans la conversation

Pourquoi React ? Pas parce que je l’aime. Mais sa popularité en fait un excellent choix pour un simple projet open source.

Créer des migrations et des modèles consiste à ajouter des entrées à une table de manière propre. Ajouter une ligne, modifier une ligne, des sélecteurs dynamiques, supprimer une ligne, etc. Toutes ces interactions devaient être instantanées. Donc la nouvelle interface utilisateur est gérée par ReactJS. Mon code JS est absolument mauvais. Je dois refactoriser certaines parties et réutiliser davantage de composants. Mais d’abord, je veux recueillir des commentaires pour voir ce qui mérite une évolution.

Grâce à l’utilisation de l’API de migration native et de ReactJS, j’ai réussi à rendre Localtower compatible avec Rails 5.2 jusqu’à Rails 8.

Conclusion

D’un côté, je suis un grand fan du code pour créer des prototypes et j’utilise la ligne de commande tous les jours. Mais de l’autre côté, je me demande pourquoi nous restons bloqués dans ce paradigme quand il s’agit de Rails. Nous avons déjà des interfaces géniales pour Sidekiq, SolidQueue (Mission Control), GoodJob, ActiveAdmin, RailsAdmin, et beaucoup d’autres outils qui vous aident à développer et surveiller les applications Rails. Pourquoi ne pas en avoir un pour les migrations de base de données ?

Si vous voulez l’essayer, je vous recommande de lire le README.md dans le dépôt Github.

Si vous voulez en discuter et partager des commentaires et des idées, vous pouvez me trouver sur X : https://x.com/damian_lnd

Vous pouvez également ouvrir un ticket sur Github ici.