Sortie de Rails 7.1

• Avec config.load_defaults 7.1, la sérialisation par défaut de ActiveSupport::MessageVerifier et ActiveSupport::MessageEncryptor passe de Marshal à ActiveSupport::JSON, tout en continuant à pouvoir lire les anciens messages Marshal
• ActiveRecord::Base.serialize n’utilise plus YAML par défaut ; l’ancien comportement peut être rétabli avec config.active_record.default_column_serializer = YAML
• Un nouveau format de cache 7.1 a été ajouté et est utilisé par défaut pour les nouvelles applications ; les applications existantes peuvent l’activer avec config.load_defaults 7.1 ou config.active_support.cache_format_version = 7.1
  • Les entrées écrites avec les formats de cache 6.1 ou 7.0 peuvent être lues avec le format 7.1
  • Lors d’un déploiement progressif de Rails 7.1, il faut conserver le format de cache lors du premier déploiement, puis activer le format de cache 7.1 lors d’un déploiement ultérieur
• Les sérialisations :message_pack et :message_pack_allow_marshal sont ajoutées à MessageEncryptor, MessageVerifier et config.active_support.message_serializer, avec la gem msgpack >= 1.7.0 requise
• Empêche l’exposition de valeurs secrètes dans inspect pour ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration et les objets de chiffrement Active Record, et renforce la protection XSS de ActionView::Helpers et ERB::Util
• has_secure_password ajoute la validation password_challenge et la méthode #{attribute}_salt, tandis que authenticate_by est ajouté pour réduire les attaques d’énumération basées sur le timing selon l’existence d’un compte
• Active Record étend sa prise en charge des clés primaires composites et clés étrangères composites, avec prise en charge de la syntaxe de tuples where, du tri par lots sur clés composites et de l’inférence des clés primaires composites depuis le schéma
• La prise en charge de PostgreSQL ajoute des commandes de migration pour renommer des enums, ajouter et modifier des valeurs, ainsi que la prise en charge des exclusion constraints, unique constraints, de l’option d’index INCLUDE et des index NULLS [NOT] DISTINCT
• L’adaptateur SQLite3 annonce une amélioration moyenne des performances de 2× grâce au mode Write-Ahead-Log normal syncing, à une taille de journal plafonnée, au shared memory buffer et au shared cache ; le mode strict strings, qui désactive les littéraux de chaîne entre guillemets doubles, est activé par défaut
• L’itération par lots sur une table entière dans Active Record utilise désormais par défaut une itération par plages, améliorant les performances ; dans un test PostgreSQL sur 10 millions d’enregistrements, les résultats indiqués sont querying 253s→30s, updating 288s→124s, deleting 268s→83s
• Le connection pooling de MemCacheStore et RedisCacheStore est activé par défaut ; pour le désactiver, il faut indiquer pool: false dans la configuration du cache store
• Un adaptateur pour le client de base de données Trilogy est ajouté, permettant d’utiliser adapter: trilogy ou un DATABASE_URL au format trilogy://
• Le format de tags par défaut de ActiveRecord::QueryLogs passe au format SQLCommenter ; l’ancien format reste disponible avec config.active_record.query_log_tags_format = :legacy
• Les éléments dépréciés ou supprimés incluent l’usage du singleton ActiveSupport::Deprecation, SafeBuffer#clone_empty, l’argument rewhere de #merge, deferrable: true dans add_foreign_key, TestFixtures#fixture_path, ainsi que le nettoyage de plusieurs configurations et API Active Record dépréciées
• ActionView::TestCase.register_parser est ajouté aux tests Action View afin d’enregistrer des parseurs pour les résultats de rendu ; les parseurs :html et :json sont fournis par défaut

[GN⁺]

Avis sur Hacker News

• Rails est excellent, et il est aujourd’hui meilleur que jamais.
  Au début de ma carrière, j’utilisais surtout Django et Laravel, puis je suis passé au travail frontend courant d’aujourd’hui, avant de reprendre cette année un projet Rails + Hotwire.
  J’ai été sincèrement surpris de voir à quel point tout était devenu simple, et je trouve dommage que la plupart d’entre nous aient oublié que cela pouvait être aussi facile. Il est aussi inquiétant que les personnes qui arrivent aujourd’hui dans le secteur puissent ne jamais connaître cette simplicité.
  Si vous n’avez jamais essayé Rails, ou si vous l’avez écarté parce que vous avez seulement entendu des choses du genre « PHP est moche / Rails est mort / JavaScript est bordélique », je vous conseille d’ignorer un moment ce que disent les autres et de l’essayer avec l’esprit ouvert.
  Ce n’est peut-être pas le meilleur choix dans un environnement où 1 000 ingénieurs travaillent sur le même dépôt, mais pour les petites équipes, il n’a pas de concurrent et il est très loin devant le reste. Honnêtement, Laravel est peut-être à peu près aussi bon.

  • J’aimerais aussi ajouter Phoenix LiveView à cette liste.
    À mon avis, Rails gagne toujours sur la vitesse de développement initiale. Ses conventions sont tellement denses et bien conçues que presque rien n’arrive à suivre. Laravel est en train de rattraper son retard, mais je ne pense pas qu’il y soit encore.
    En revanche, LiveView passe mieux à l’échelle dans tous les sens du terme. Il fournit aussi beaucoup de choses par défaut — authentification, accès à la base de données, files de jobs, mailer, outillage de test complet, etc. — permet de presque ne pas écrire directement de JavaScript, et s’appuie sur l’excellente machine virtuelle BEAM.
    Au minimum, c’est agréable que tous ces projets mènent le combat du « prenons un peu de recul ». Au travail, nous utilisons React et Relay, et même si j’écris du JavaScript frontend depuis longtemps et que je pense m’en sortir correctement, il y a tellement d’obstacles à franchir que c’en est épuisant.
  • Comparé à Django, je trouve intéressant qu’au moins aujourd’hui, les deux ne soient pas considérés comme équivalents. Je me demande s’il existe des raisons précises de préférer Rails à Django.
  • J’aime Rails, mais dans mon pays, presque personne ne l’utilise, et les entreprises qui l’utilisent cherchent presque toujours des développeurs de niveau magicien.
    Comme je ne trouve pas de poste, je n’accumule pas assez d’expérience, et je finis par me faire dépasser par ces magiciens. Certaines de ces offres restent ouvertes plus de 12 mois.
    À la place, comme c’est là qu’il y a de la demande, je répands encore plus de JavaScript dans le monde.
  • Beaucoup de développeurs Rails que je connais sont passés à ember.js. C’est parce qu’ember.js est aussi un framework fondé sur des conventions, plutôt qu’un écosystème où d’innombrables plugins tiers cassent en permanence.
    Sur le plan structurel, j’aime l’approche d’ember-data. Il y a beaucoup de choses automatisables pour des opérations comme les jointures gauche/droite sur des jeux de données, et il y a aussi un serveur mock intégré.
    Cela dit, comme ça marche trop bien, il semble peut-être moins séduisant que d’autres solutions.
    https://emberjs.com/

• J’ai migré une application Rails 7.0 de 13 000 lignes vers 7.1 et, à part les différences entre 7.0 et 7.1[0], tout fonctionnait après n’avoir modifié qu’une seule ligne de configuration de test.
  En matière de chemin de mise à niveau simple, je considère que c’est une réussite. La partie intéressante maintenant, c’est de refactorer une partie du code pour utiliser les nouveautés de 7.1.
  Si cela vous intéresse, j’ai aussi mis à jour vers 7.1 une application d’exemple Rails / Docker : https://github.com/nickjj/docker-rails-example
  Rails 7.1 inclut bien un Dockerfile, mais il reste beaucoup d’options à ajouter, par exemple utiliser Docker Compose pour créer une expérience qui fonctionne directement en développement comme en production, avec Postgres, Redis, Action Cable, Sidekiq, etc.
  [0] : https://railsdiff.org/7.0.8/7.1.0

• Je suis en train d’essayer de faire évoluer une grosse base de code Rails 6, avec beaucoup de React greffé dessus, vers une nouvelle approche « non » JavaScript utilisant Hotwire. Souhaitez-moi bonne chance
  Rails est excellent quand on respecte ses valeurs par défaut, mais dès qu’on s’en écarte, on entre en territoire douloureux

  • Je travaille sur une base de code Rails 7 relativement récente. Au départ, nous avons commencé avec Stimulus, mais nous envisageons de passer à React pour plusieurs raisons
    Pour recruter des ingénieurs frontend, le vivier de candidats React est plusieurs ordres de grandeur plus grand. Trouver des packages JavaScript vanilla pour des tâches courantes et les envelopper dans des contrôleurs Stimulus devient aussi de plus en plus difficile que de trouver des packages React
    Stimulus ne propose pas vraiment non plus de moyen d’écrire des tests unitaires de contrôleurs. Avec React, on peut utiliser jest et react-test-renderer comme d’habitude
    En plus, la récente controverse Turbo TypeScript n’a pas inspiré confiance dans l’exploitation à long terme de l’écosystème Hotwire
    Nous n’avons pas encore pris de décision. Le fait que Stimulus ressemble à une façon très « Rails » d’écrire du code frontend est clairement un avantage, surtout pour une petite équipe déjà familière avec Rails
  • « Rails est bien si l’on respecte les valeurs par défaut, et douloureux dès qu’on s’en écarte » vaut pour tous les frameworks
    Si l’application est assez simple et correspond bien à la façon de faire du framework, celui-ci est excellent. Si vous avez besoin d’une configuration plus complexe et flexible, il faut regarder du côté des bibliothèques
  • J’ai perdu confiance dans l’intégration JavaScript de Rails
    Désormais, soit je fais du rendu côté serveur avec slim, soit je construis Rails en mode API only et je sépare le frontend
    Rails a trop souvent changé de direction pour faire du JavaScript : CoffeeScript, précompilation des assets, webpack, etc.
  • Je ne recommanderais pas de migrer un frontend React existant vers Hotwire en même temps qu’une mise à niveau de Rails lui-même. À mon avis, mieux vaut d’abord passer indépendamment à Rails 7.1
    À noter que la manière de gérer le JavaScript d’une application monopage dans Rails 7+ est aussi bien plus raisonnable qu’avant. En pratique, on utilise l’outil de build que l’on veut, séparément de l’app Rails
    En développement, il faut lancer quelque chose comme yarn build --watch en même temps que rails s, mais personnellement je trouve que ce n’est pas mal et que c’est beaucoup plus simple
    Notre entreprise développe un logiciel qui automatise les mises à niveau Rails, et nous proposons aussi un service complet où nous faisons les mises à niveau Rails à votre place. Si cela vous intéresse, contactez steve (at) infield.ai ou créez gratuitement un plan de mise à niveau Rails sur https://app.infield.ai/users/sign_up. Aucune carte bancaire n’est nécessaire
    Pour plus de détails, voir https://docs.infield.ai/docs/creating-an-upgrade-path
  • Je recommande d’essayer https://vite-ruby.netlify.app/guide/rails.html
    Dans mon cas, cela s’est quasiment inséré comme un remplaçant de webpack

• J’aime Rails et je l’utilise par intermittence depuis Rails 2
  C’est un très bon framework et, pour quelqu’un comme moi qui doit lancer un site web de temps en temps, c’est vraiment le chemin de moindre résistance
  En revanche, configurer un nouvel ordinateur portable pour faire tourner Rails est pénible. Il faut node, donc il faut aussi npm. Comme je suis développeur backend, je ne sais pas vraiment comment configurer node ni dans quel ordre procéder
  Comme ce n’est pas quelque chose que je fais souvent, ça ressemble à une lutte à chaque fois. Je finis par y arriver, mais je ne suis jamais sûr de comprendre pourquoi tout a fini par s’aligner
  J’aimerais qu’il existe un installateur qui mette en place tout ce qu’il faut d’un coup pour que rails fonctionne simplement. L’installateur rvm configure rails au-dessus de ruby, mais il ne configure pas tout le système node en dessous

  • Le gestionnaire de versions asdf est bien pour gérer nodejs. Je ne l’ai jamais utilisé pour Ruby
    https://asdf-vm.com/
  • Je comprends l’idée de « je suis développeur backend, donc je ne sais pas configurer node »
    Node est surtout connu comme outil frontend, et Rails l’utilise aussi dans ce but, mais si je me souviens bien, Node a au moins été créé au départ pour amener le runtime JavaScript côté backend
    Sans gestionnaire de packages, sous Windows c’est simplement node.exe, et il me semble qu’il suffit de télécharger et décompresser npm, puis d’ajouter node et npm à la variable d’environnement PATH
  • Tout le principe de Rails 7 est justement de supprimer la dépendance à node
  • Je n’ai jamais fait de Rails, donc je suis curieux : j’aimerais savoir pourquoi « Ruby on Rails » a besoin de nodejs
    Et installer node est assez simple. En fait, trop simple. J’aimerais que ce soit beaucoup plus difficile et qu’il faille un diplôme
  • La communauté Ruby/Rails est l’une des meilleures et des plus bienveillantes que j’aie vues. Mais ce qu’elle a de pire, de loin, c’est sa haine de JavaScript
    JavaScript n’est qu’un outil, comme les autres. Qu’on l’aime ou non, c’est un outil très important et, qu’on l’aime ou non, il va rester longtemps
    Avec un peu d’ouverture d’esprit et en apprenant au moins les bases, les choses deviendraient plus simples

• J’aimerais voir revenir en force Rails + HTMX, avec juste un peu de JavaScript saupoudré uniquement sur les pages très interactives
  Utiliser Rails avec Slim/HAML est vraiment agréable. Si on le souhaite, on peut aussi faciliter le rendu partiel avec une bibliothèque comme ViewComponents. En y ajoutant des web components, on peut créer des pages assez interactives, et utiliser React sur une page précise si c’est vraiment nécessaire
  HATEOAS réduit fortement la complexité des applications. Et si une API reste nécessaire, il est très facile de répondre à différents types MIME, voire de partager le même endpoint si on le souhaite
  D’après mon expérience, la plupart des applications qui utilisent React n’en ont en réalité pas du tout besoin. Elles utilisent React pour quelques menus contextuels
  Donc, si de grosses apps sans React, ou avec seulement très peu de React, commencent à apparaître, j’espère que certains réaliseront à quel point nos applications actuelles sont inutilement complexes
  Mais je vois déjà des gens dire : « tout le monde utilise React, donc il faut passer à React ». Soupir
  On peut toujours rêver

• L’annonce officielle est ici : https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Il y a un peu plus de détails de haut niveau, et j’ai hâte d’essayer certaines des nouveautés. En particulier, les nouvelles méthodes de requêtes asynchrones semblent pouvoir être très utiles pour obtenir rapidement de meilleures performances.

• Rails côté backend ne reçoit pas toute la reconnaissance qu’il mérite
  Cela dit, côté frontend, ça a été le bazar pendant très longtemps

  • Je ne suis pas contre l’idée que « côté frontend, ça a été le bazar pendant longtemps », mais le frontend lui-même a aussi été un bazar pendant longtemps
    Aujourd’hui, travailler avec Rails 7.1 + Hotwired + Importmaps est agréable
    Mais il a fallu attendre que les navigateurs prennent correctement en charge au minimum ES6 et Import Maps
    Si l’on regarde la date de cet article, https://web.dev/import-maps-in-all-modern-browsers/ annonçait le 28 mars 2023 qu’on pouvait utiliser les importmaps dans tous les navigateurs modernes
    Donc, jusqu’ici, il n’y avait pas vraiment moyen d’éviter Webpack, Yarn et les autres outils JavaScript auxiliaires
    Maintenant qu’il y a importmaps et que la prise en charge d’ES6 par les navigateurs est suffisamment bonne, https://caniuse.com/?search=es6, on peut écrire du JavaScript moderne avec très peu d’outillage supplémentaire
  • D’accord. Quelles sont les options ici ? Rails en mode API only ?
  • J’aime les nouvelles fonctionnalités de Hotwire. Je me demande ce qui ne te plaît pas côté frontend

• Il y a quelques semaines, un ami a plaisanté : « Si une release de Rails est annoncée et que tu n’as pas ouvert de PR d’upgrade, est-ce que c’est vraiment arrivé ? »
  Bon, il est temps d’ouvrir la PR. Même si je dois l’empiler derrière une PR 7.0 en attente depuis des mois

• D’après mon expérience, beaucoup d’équipes ont du mal à construire une codebase propre avec ActiveRecord

• Ne me tapez pas dessus, mais j’utilise encore Rails 4.2 et j’en suis satisfait
  Il fournit tout ce dont j’ai besoin pour les backends SaaS sans JavaScript, ou avec très peu, que je fais pour moi-même ou pour des entreprises B2B, et il tourne même sur des VPS modestes
  Si vous avez le temps de répondre, je serais curieux de savoir pourquoi je devrais upgrader

  • J’utilise aussi une ancienne version. Pour commencer, il faut vérifier si tu peux au moins passer à la dernière version de patch/mineure
    Le principal problème des anciennes versions, ce sont les vulnérabilités des gems liées. Par exemple, nokogiri peut ne pas pouvoir être mis à jour sans upgrade majeure de Rails
    Cela dit, la plupart des apps ne font pas, par exemple, de parsing XML complexe, donc beaucoup de vulnérabilités ne s’appliquent pas. Il faut donc un peu de maintenance pour vérifier que c’est sûr. Il est aussi fréquent d’ajouter des monkey patches pour éviter des bugs
    Upgrader améliore la sécurité et réduit le temps de maintenance. Mais il faut aussi tenir compte du coût des upgrades incessants. Un autre facteur est que les nouvelles versions peuvent prendre en charge des versions plus rapides de Ruby
    En général, quand je crée une app Rails, j’utilise la dernière release, mais ensuite je ne monte pas de version de Rails sauf si l’app devient populaire ou très ancienne et que quelque chose ne fonctionne plus sur un nouveau système
  • Il faut upgrader pour des raisons de sécurité