Rails pour tout - La puissance de Rails pour tout faire

 (literallythevoid.com)
7 points par GN⁺ 2025-01-03 | 2 commentaires | Partager sur WhatsApp
  • Rails 8 est très utile pour les petits projets et les développeurs solos
  • Avec le guide de démarrage le plus récent, il est possible de construire facilement des applications de niveau production
  • Les améliorations de SQLite permettent de déployer un environnement de base de données solide sans serveur supplémentaire
  • Les CI intégrées et le générateur d'authentification améliorent l'efficacité du développement et la sécurité
  • Le déploiement simplifié via Kamal permet d'exécuter un service rapidement et en toute sécurité

Aperçu

  • En se basant sur l'expérience de Rails 8, c'est un excellent framework web pour les petits projets et les développeurs solo
  • Grâce à la construction rapide, au déploiement efficace et aux modules intégrés, il se distingue des frameworks concurrents par ses avantages en matière de productivité

Les points forts du guide de démarrage le plus récent

  • Le guide récent Getting Started with Rails est conçu pour permettre même à un débutant de créer une application de production
  • L'installation de Ruby reste complexe, mais en suivant simplement le guide, il est possible de bâtir un service robuste intégrant authentification, mise en cache, texte enrichi, intégration continue et base de données
  • Sa principale force est d'offrir des bases et des fonctions de niveau service réel, et non un simple « Hello World »
  • Il devient un point de départ idéal pour les novices qui ne sont pas encore à l'aise avec Rails

SQLite suffit à lui seul

  • SQLite est un excellent outil de base, mais jusqu'ici sa configuration pour la production était difficile
  • Auparavant, il fallait parfois installer des gems supplémentaires, mais avec Rails 8, il peut désormais être utilisé de façon fiable en production sans travaux supplémentaires
  • Il n'est pas nécessaire d'installer PostgreSQL ni de lancer un serveur dédié ; avec solid cache, un serveur Redis n'est pas non plus requis
  • Un service peut fonctionner uniquement avec Rails et SQLite, ce qui maximise la simplicité de mise en place et l'efficacité des coûts

Intégration continue (CI) simplifiée

  • Dès les premiers commits, une notification d'échec de CI peut être reçue, preuve qu'une configuration CI intégrée est fournie par défaut avec Rails 8
  • L'intégration avec GitHub Actions est prête à l'emploi et offre 2 000 minutes d'exécution gratuites chaque mois
  • Pour un développeur solo, cela représente un temps largement suffisant

Introduction du générateur d'authentification

  • Les gems d'authentification comme Devise sont puissantes, mais leur complexité de configuration les rendait assez difficiles pour les débutants
  • Rails 8 ajoute un générateur d'authentification simple ; en ajoutant uniquement les utilisateurs existants depuis la console, il est facile d'implémenter le flux de connexion
  • Le code généré est simple et facile à lire, ce qui facilite la compréhension pour les débutants

Déploiement simple et rapide avec Kamal

  • Le processus de déploiement est pris en charge par Kamal : il suffit de modifier partiellement le fichier deploy.yml et de suivre les instructions pour lancer l'application immédiatement en environnement SSL
  • C'est une expérience de déploiement d'application web plus rapide que la configuration SSL sur GitHub Pages
  • La combinaison d'une CI intégrée et d'un déploiement simple est l'un des atouts les plus marquants de Rails 8
  • En suivant uniquement le guide de démarrage, on bénéficie d'une expérience de développement conforme aux meilleures pratiques récentes

Conclusion

  • Rails reste un framework puissant et en constante évolution
  • Si vous envisagez un nouveau projet cette année, cela vaut la peine d'essayer de développer en Rails 8

À lire aussi

2 commentaires

 
aer0700 2025-01-06

Il y a de plus en plus d’articles sur SQLite en ce moment, et maintenant on en est même à proposer SQLite pour tout.
Doit-on parler d’un renouveau du classique ?
 
GN⁺ 2025-01-03
Avis sur Hacker News
  • Aujourd'hui, je développe des applications avec la stack Spring Boot et Micronaut, y compris un frontend React. L'approche omakase (tout fourni) de Rails m'est vraiment précieuse. Même des fonctions simples venant du backend, comme la validation de formulaires ou les messages flash, ne sont pas résolues directement par le framework, donc je dois les implémenter moi-même ou chercher une solution tierce. Rails résout à l'avance les problèmes rencontrés par 90 % des webapps. Ce n'est pas parfait, mais dans la plupart des cas les fonctionnalités embarquées suffisent, et on peut toujours les remplacer si nécessaire.
    • Avec Spring Boot, la validation de formulaire est presque fournie par défaut et possible immédiatement via des annotations.
  • Je pense que Rails et Django sont tous les deux de très bons frameworks. J'ai aussi écrit des applications mission critical en Python. Mais j'ai envie de passer à Go pour les développements de grands monolithes, parce que je ressens que le système de types de Go et sa concurrence sont plus puissants. Le problème, c'est que le monde Go ne parvient pas à offrir un écosystème de frameworks comparable à Rails ou Django. Go est excellent pour fabriquer des outils réseau ou des CLI, mais pour créer vite une webapp full-stack, je choisis encore Rails ou Django. Je n'arrive pas vraiment à croire au slogan “Rails est terminé”.
    • Avec des outils comme ogen, on peut générer automatiquement la plupart des fonctionnalités à partir d'un seul document OpenAPI : routeur statique, validation des requêtes/réponses, supervision Prometheus, tracing OpenTelemetry, etc. On peut aussi générer le code client et webhook. Pour l'auth, il suffit d'ajouter une seule fonction. En combinant sqlc avec pragma user_version de SQLite, le code de DB avec types sûrs et les migrations deviennent faciles. Ajouter SQLite, c'est juste deux lignes d'import dans main.go. Les templates standards de Go suffisent déjà pour le traitement de texte côté frontend, et avec embed, on intègre facilement les assets statiques dans le binaire. Le déploiement se résume souvent à go build puis déplacer le binaire, donc la mise en production est très simple. Grâce aux outils de génération de code, le dev backend Go est devenu très rapide et pratique.
    • J'ai aussi voulu une stack entièrement en types statiques, et de façon claire, c'est ASP.NET qui était la bonne réponse, plutôt que Go ou Rust. Microsoft met beaucoup en avant les nouveaux produits (p. ex. Aspire.NET), mais en réalité c'est .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) qui est vraiment battery-included et fiable. Il faut un léger basculement de mindset OOP et DI, mais pour un développeur expérimenté, ce n'est pas un vrai problème.
    • Le problème de l'écosystème Go est la mentalité anti-framework, mais aussi la mentalité anti-fonctionnalités modernes. Java, Kotlin, Scala, C#, F# etc. sont aussi très bons pour les outils réseau ou le développement CLI. Aujourd'hui, Java AOT peut être utilisé sans souci de licence commerciale et .NET n'est plus enfermé sur Windows.
    • Je recommande Encore. Surtout, il est très puissant pour intégrer un PaaS (comme la combinaison NextJS+Vercel). C'est un peu différent des principes de Go, mais c'est un excellent choix pour les petites équipes ou une équipe d'une personne. Si besoin, on peut déployer via BYOC ou même monter soi-même la couche API avec la stdlib. Le frontend demande NextJS ou Remix/RR7, mais l'intégration est très simple grâce à la génération automatique d'un SDK client TypeScript. Encore a aussi l'intégration Vercel PR, ce qui est là aussi un gros avantage.
    • En Go, l'outil qui s'approche le plus d'une expérience type Django est sans doute beego. Mais je trouve qu'il manque encore de maturité pour être mis au niveau de Django ou Rails.
    • J'ai un projet en cours en Go, et je suis vraiment satisfait d'avoir un code propre. L'IA aide énormément à franchir la barrière d'entrée du framework. Je pense toutefois que Rails est plus adapté pour un service client, et que django est plus intuitif pour les outils internes et le travail sur les données.
    • Ruby permet aussi des contrôles de types avec Sorbet, et la fonctionnalité de concurrence supportée par Fiber est pratiquement aboutie. Un nouveau serveur web nommé Falcon est en cours de construction sur Fiber. Ce n'est pas encore au niveau de Puma, mais son usage production arrivera probablement bientôt.
    • L'auteur du langage Stanza a écrit un texte sur l'insight suivant : pour qu'un framework puissant (à la Rails), il faut des prérequis au niveau du langage lui-même. Le fait qu'il n'existe pas de tel framework en Go ou en Java est le résultat d'une combinaison des limites du langage (ou des limites du programmeur).
    • Go n'a pas été pensé au départ comme orienté vers des frameworks full-stack du type Rails/Django.
    • Node/Express convient au niveau picoservice pour développeurs locaux, et ASP.NET WebAPI/MVC est pour moi le backend idéal.
    • Il vaut peut-être le coup d'essayer goravel dev.
  • En suivant les Rails Guides du début à la fin, on peut lancer un vrai service comprenant authentification, caching, rich text, CI et DB. Mais cela peut être une perte de temps en startup early-stage d'ajouter d'emblée toutes les fonctionnalités additionnelles/embarquées comme Devise, turbo, tests, etc. Turbo a l'avantage d'accélérer le chargement des pages, mais peut aussi allonger le temps de développement quand ça entre en conflit avec Devise. Si vous êtes en phase de validation d'idée avant la mise en ligne, sauf pour les apps bancaires/médicales, il est possible d'ajourner tests et CI sans trop de risque. L'important est de ne pas céder au biais du défaut (on l'utilise parce que c'est présent) et de refuser avec assurance : “pour l'instant je n'en ai pas besoin”.
    • Si vous concevez une app SaaS, partir avec des templates Rails dédiés comme Jumpstart Pro ou Bullet Train permet de gagner plusieurs mois de développement. Les fonctionnalités de base comme paiement, auth y sont déjà incluses, et l'extension est ensuite simple.
    • Je ne suis pas d'accord sur la posture vis-à-vis des tests. Même une petite app gagne du temps quand elle a du code de test. La CI se résume souvent à un fichier d'une vingtaine de lignes, que j'ai déjà copié-collé dans d'anciens projets.
    • La CI est un facteur qui accélère le développement. Elle vaut mieux être ajoutée dès les toutes premières étapes du projet.
    • Je me demande à quel moment il faut passer de Flask/Express/Sinatra/Gradio/Hono à Rails.
  • Le Rails le plus récent a vraiment l'air beaucoup plus flashy, et ça me fait plaisir. J'ai maintenu pendant 12 ans, depuis Rails 2.3, divers apps ; aujourd'hui Rails a un tout autre Pokémon en pleine évolution. L'Upgrade Guide Rails est d'ailleurs très bien documenté, donc j'ai pu suivre une migration propre d'un seul tenant sans gros refactoring. Ce n'est pas rétrocompatible, mais le fait que les changements soient clairement documentés est un gros avantage. ActiveStorage a aussi fait énormément progresser la gestion des pièces jointes, et même si la transition vers Webpacker a été un peu pénible, les Import Maps semblent désormais rendre les choses plus simples. J'ai prévu de migrer en 8.1 cette année.
    • Il y a 4 ans, j'ai choisi de maintenir une app Rails ancienne malgré un budget serré, en acceptant une baisse de salaire (à l'époque Ruby 2.3). Le résultat : être capable de faire facilement des mises à jour et d'ajouter des fonctionnalités m'a vraiment satisfait.
  • Je développe seul un projet open source Rails qui supporte 120 000 utilisateurs par mois, et je suis en grand accord avec l'affirmation de ce post. En plus, la gestion des pièces jointes d'ActiveStorage est vraiment excellente. Pour le déploiement, j'ai surtout utilisé Dokku, mais j'ai hâte d'essayer Kamal. Rails continue d'évoluer, et Ruby devient de plus en plus rapide.
    • Si vous aimez Dokku, je me demande si vous avez déjà testé les Cloud Native Buildpacks. Ça permet aussi de générer directement une image OCI.
  • Ruby est trop peu présent dans mon parcours car je n'y ai pas beaucoup de part web, donc je connaissais surtout Django. Je me demande quelles sont les différences entre les deux frameworks.
    • Je connais bien les deux écosystèmes (même si j'ai moins utilisé Rails récemment). Django est lié à Python, Rails à Ruby/gem, donc l'impact de l'écosystème est important. Le CMS Django admin est clairement plus robuste que chez Rails, et beaucoup d'organisations utilisent entièrement Django pour leurs CMS internes. Rails dispose d'un gigantesque scaffolding CLI, donc c'est très rapide pour créer des fonctions CRUD. Rails est plus élevé en niveau d'abstraction et la structure/architecture sont quasi imposées par Rails, alors que Django impose de choisir bien plus de décisions par soi-même. Rails insiste davantage sur DRY et la prévention de la duplication de code. Ceux qui privilégient l'intuition pythonique peuvent trouver la magie de Rails pesante, tandis que les railsiens peuvent trouver répétitif l'approche Python. Essentiellement, les styles diffèrent.
    • Si je devais créer une web app (produit orienté utilisateur final), je prendrais d'abord Rails, car le scaffolding et l'industrialisation du produit me semblent plus simples (je n'ai pas d'expérience réelle en très grand service). Pour les outils internes, le travail data ou la géodonnée, Python/Django est préférable.
    • La plus grande différence est entre Python et Ruby. L'écosystème Python est immense, et Django intègre l'authentification ainsi qu'une admin intégrée.
    • Je trouve l'expérience de test meilleure avec Rails. Rails fournit à la fois la config CI et la génération automatique du code de test.
    • Selon mon expérience, Django Admin est beaucoup plus flexible et plus facile à utiliser que l'alternative côté Ruby. Côté tests et routing, en revanche, Rails est meilleur et ses conventions sont plus fortes. Je préfère ActiveRecord+arel à Django ORM. (Personnellement, écrire du code Ruby est plus agréable que du Python.)
    • Apprendre Ruby n'est pas très difficile, et Rails fournit beaucoup plus de structure et de conventions dès le départ que Django.
  • Beaucoup de gens ont pour Rails une forme d'attachement émotionnel proche de l'amour, et je ne ressens pas ce niveau, au point de m'en envier parfois. Chaque langage ou framework a sa base de fans, mais l'intensité côté Rails est un peu spéciale.
    • Il y a beaucoup de points où les conventions de Rails me gênent, mais une fois qu'on essaie d'obtenir une productivité comparable dans un backend JavaScript, c'est presque impossible. Inversement, lorsque l'on prend la main sur du code Rails, on voit souvent des cas où des fonctionnalités de base de Rails (p. ex. Active Job) ont été réimplémentées sans raison valable. Suivre les conventions est souvent plus efficace.
  • En ayant utilisé SQLite en production, j'ai fini par galérer sur des questions de migration. Par exemple, pour ajouter une contrainte NOT NULL à une colonne existante, il faut réécrire toute la table via une table temporaire.
    • SQLite n'a pas non plus d'ADD CONSTRAINT, ni de langage PL ou de stored proc simple, donc il faut sans cesse faire des allers-retours en langage hôte, surtout fastidieux avec des langages statiquement typés.
    • Je pense que Postgres reste le meilleur et qu'il est difficile de l'abandonner. Néanmoins, le fait que sqlite3 entre dans Rails en tant qu'option de première classe est une avancée positive.
    • La recommandation par défaut de Rails dit parfois que sqlite peut remplacer redis, mais en pratique ce n'est utile que pour démarrer un petit service. Si vous allez migrer plus tard vers une autre DB, je ne recommande pas de commencer avec sqlite, parce que la migration est toujours douloureuse.
    • Rails peut gérer la plupart des cas avec la validation ActiveRecord, mais il y a des limites à refléter les contraintes fondamentales.
  • Le guide d'installation de Ruby est un peu compliqué. En remontant un blog Jekyll après 15 ans, j'ai eu pas mal de difficultés avec l'usage des gems, etc. Ce n'était pas totalement de leur faute, je me suis aussi trompé ; mais ça aurait été bien plus simple si c'était plus accessible. Cela m'a pourtant donné envie de retenter Ruby.
    • La configuration doit être simple pour tout le monde. J'ai appris Jekyll rapidement parce que mon environnement avait déjà Ruby et RubyGems.
  • Si vous utilisez uniquement sqlite, litestack vaut peut-être un coup d'œil. Je ne l'ai jamais utilisé directement, mais je prévois de passer un projet perso de Postgres à litestack. Les performances de benchmark sont vraiment impressionnantes.
    • SQLite a été considérablement renforcé dans Rails 8, donc je me demande s'il faut vraiment litestack. J'aimerais savoir quels sont les éléments différenciants.