Rails 7.1 veröffentlicht

• Bei Verwendung von config.load_defaults 7.1 wird die Standardserialisierung von ActiveSupport::MessageVerifier und ActiveSupport::MessageEncryptor von Marshal auf ActiveSupport::JSON geändert; bestehende Marshal-Nachrichten können weiterhin gelesen werden
• ActiveRecord::Base.serialize wird so geändert, dass standardmäßig nicht mehr YAML verwendet wird; das bisherige Standardverhalten kann mit config.active_record.default_column_serializer = YAML wiederhergestellt werden
• Ein neues Cache-Format 7.1 wurde hinzugefügt und wird als Standard für neue Apps verwendet; bestehende Apps können es mit config.load_defaults 7.1 oder config.active_support.cache_format_version = 7.1 aktivieren
  • Einträge, die im Cache-Format 6.1 oder 7.0 geschrieben wurden, können im Format 7.1 gelesen werden
  • Bei Rolling Deployments von Rails 7.1 sollte im ersten Deployment das Cache-Format beibehalten und erst in einem späteren Deployment das Cache-Format 7.1 aktiviert werden
• Die Serialisierungen :message_pack und :message_pack_allow_marshal werden zu MessageEncryptor, MessageVerifier und config.active_support.message_serializer hinzugefügt; erforderlich ist das msgpack-Gem >= 1.7.0
• ActiveSupport::KeyGenerator, MessageEncryptor, EncryptedConfiguration und Active-Record-Verschlüsselungsobjekte verhindern in inspect die Offenlegung geheimer Werte, und der XSS-Schutz in ActionView::Helpers und ERB::Util wurde verstärkt
• Zu has_secure_password kommen die Prüfung password_challenge und die Methode #{attribute}_salt hinzu, und authenticate_by wird ergänzt, um timingbasierte Enumeration-Angriffe abhängig von der Existenz eines Kontos zu verringern
• Die Unterstützung in Active Record für zusammengesetzte Primärschlüssel und zusammengesetzte Fremdschlüssel wurde erweitert; unterstützt werden Tupel-Syntax in where, Batch-Sortierung nach zusammengesetzten Schlüsseln und die Ableitung zusammengesetzter Primärschlüssel aus dem Schema
• Für PostgreSQL kommen Migrationsbefehle zum Umbenennen von Enum-Namen, zum Hinzufügen und Ändern von Werten, außerdem Exclusion Constraints, Unique Constraints, Indexoptionen mit INCLUDE sowie Index-Unterstützung für NULLS [NOT] DISTINCT hinzu
• Der SQLite3-Adapter weist mit Einstellungen für Write-Ahead-Log normal syncing mode, begrenzte Journal-Größe, Shared-Memory-Buffer und Shared Cache im Durchschnitt eine 2× höhere Leistung auf; außerdem ist der Strict-Strings-Modus, der doppelt quotierte String-Literale deaktiviert, standardmäßig aktiviert
• Die Batch-Iteration über ganze Tabellen in Active Record verwendet standardmäßig Range Iteration und verbessert so die Leistung; bei einem PostgreSQL-Test mit 10 Millionen Datensätzen werden Ergebnisse von querying 253s→30s, updating 288s→124s, deleting 268s→83s genannt
• Connection Pooling ist für MemCacheStore und RedisCacheStore standardmäßig aktiviert; zum Deaktivieren muss in der Cache-Store-Konfiguration pool: false gesetzt werden
• Ein Adapter für den Datenbank-Client Trilogy wurde hinzugefügt, sodass adapter: trilogy oder ein DATABASE_URL im Format trilogy:// verwendet werden kann
• Das Standard-Tag-Format von ActiveRecord::QueryLogs wird auf das Format von SQLCommenter umgestellt; mit config.active_record.query_log_tags_format = :legacy kann das bisherige Format weiter genutzt werden
• Zu den Deprecations und Entfernungen gehören die Verwendung des ActiveSupport::Deprecation-Singletons, SafeBuffer#clone_empty, das Argument rewhere von #merge, deferrable: true bei add_foreign_key, TestFixtures#fixture_path sowie die Bereinigung mehrerer veralteter Active-Record-Einstellungen und APIs
• Für Action-View-Tests wurde ActionView::TestCase.register_parser hinzugefügt, um Parser für Rendering-Ergebnisse zu registrieren; als Standardparser werden :html und :json bereitgestellt

[GN⁺]

Meinungen auf Hacker News

• Rails ist großartig und heute besser denn je
  Zu Beginn meiner Karriere habe ich hauptsächlich Django und Laravel verwendet, bin später zu der heute üblichen Frontend-Arbeit gewechselt und habe dieses Jahr wieder ein Rails-+Hotwire-Projekt übernommen
  Ich war wirklich überrascht, wie einfach alles geworden ist, und finde es schade, dass die meisten vergessen haben, dass es so leicht sein kann. Beängstigend ist auch, dass Leute, die jetzt in die Branche kommen, diese Einfachheit womöglich gar nicht mehr erleben
  Wenn du Rails noch nicht ausprobiert hast oder es beiseitegelegt hast, weil du nur Dinge wie „PHP ist hässlich / Rails ist tot / JavaScript ist chaotisch“ gehört hast, empfehle ich dir, die Meinungen anderer kurz zu ignorieren und es mit offenem Kopf einmal auszuprobieren
  Für eine Umgebung, in der 1.000 Engineers am selben Repository arbeiten, ist es vielleicht nicht die beste Wahl, aber für kleine Teams gibt es keine Konkurrenz, und es ist allem anderen weit voraus. Ehrlich gesagt könnte Laravel ungefähr ähnlich gut sein

  • Hier würde ich auch Phoenix LiveView nennen
    Bei der anfänglichen Entwicklungsgeschwindigkeit gewinnt Rails meiner Meinung nach immer. Die Konventionen sind so dicht und gut durchdacht, dass kaum etwas in die Nähe kommt. Laravel holt zwar auf, aber noch ist es nicht so weit
    LiveView skaliert allerdings in jeder Hinsicht besser. Es bringt viel von Haus aus mit, etwa Authentifizierung, Datenbankzugriff, Job-Queues, Mailer und vollständige Testwerkzeuge, man muss fast kein eigenes JavaScript schreiben, und außerdem gibt es mit BEAM eine hervorragende virtuelle Maschine
    Gut ist zumindest, dass all diese Projekte den Kampf dafür führen, „einen Schritt zurückzutreten“. Bei der Arbeit nutzen wir React und Relay, und obwohl ich lange Frontend-JavaScript gemacht habe und denke, dass ich es einigermaßen beherrsche, sind die Hürden, die man nehmen muss, einfach ermüdend
  • Im Vergleich zu Django finde ich interessant, dass du die beiden zumindest derzeit nicht auf eine Stufe stellst. Mich würde interessieren, ob es konkrete Gründe gibt, Rails gegenüber Django zu bevorzugen
  • Ich mag Rails, aber in meinem Land nutzt es fast niemand, und die Firmen, die es nutzen, suchen praktisch Entwickler auf Zauberer-Niveau
    Weil ich keine Stelle finde, kann ich auch nicht genug Erfahrung sammeln und werde am Ende von solchen Zauberern verdrängt. Manche dieser Stellenausschreibungen sind seit über 12 Monaten offen
    Stattdessen verbreite ich noch mehr JavaScript in der Welt, weil dort Nachfrage besteht
  • Viele Rails-Entwickler, die ich kenne, sind zu ember.js gewechselt. Der Grund ist, dass ember.js ebenfalls ein konventionsbasiertes Framework ist und nicht nach dem Muster funktioniert, dass ständig zahllose Third-Party-Plugins kaputtgehen
    Strukturell gefällt mir der ember-data-Ansatz. Bei Aufgaben wie Left Joins/Right Joins von Datensätzen lässt sich viel automatisieren, und es gibt auch einen integrierten Mock-Server
    Vielleicht wirkt es aber gerade deshalb, weil es so gut funktioniert, nicht so cool wie andere Dinge
    https://emberjs.com/

• Ich habe eine Rails-7.0-App mit 13.000 Zeilen auf 7.1 aktualisiert, und abgesehen von den Unterschieden zwischen 7.0 und 7.1[0] musste ich nur eine Zeile im Test-Setup ändern, dann lief alles
  Als einfacher Upgrade-Pfad ist das aus meiner Sicht ein Erfolg. Der spannende Teil ist jetzt, etwas Code so zu refaktorisieren, dass er die neuen Funktionen von 7.1 nutzt
  Falls es dich interessiert: Ich habe auch eine Rails-/Docker-Beispiel-App auf 7.1 aktualisiert https://github.com/nickjj/docker-rails-example
  Rails 7.1 enthält zwar ein Dockerfile, aber es gibt weiterhin viele Möglichkeiten, noch mehr zu ergänzen: etwa mit Docker Compose eine sofort funktionierende Erfahrung für Entwicklung und Produktion zu schaffen und Postgres, Redis, Action Cable, Sidekiq usw. einzubinden
  [0]: https://railsdiff.org/7.0.8/7.1.0

• Ich versuche gerade, eine ziemlich große Rails-6-Codebasis mit jede Menge React auf einen neuen „nicht“-JavaScript-Ansatz mit Hotwire zu heben. Drückt mir die Daumen
  Rails ist großartig, solange man bei den Defaults bleibt, aber sobald man davon abweicht, wird es zum Land der Schmerzen

  • Ich arbeite an einer relativ aktuellen Rails-7-Codebasis. Anfangs haben wir Stimulus verwendet, überlegen aber aus mehreren Gründen, auf React umzusteigen
    Wenn man Frontend-Engineers einstellen will, ist der Pool an React-Kandidaten um Größenordnungen größer. Es wird auch immer schwieriger, Vanilla-JavaScript-Pakete für gängige Aufgaben zu finden und sie in Stimulus-Controller zu verpacken, als einfach React-Pakete zu finden
    Stimulus bietet auch keine wirkliche Möglichkeit, Unit-Tests für Controller zu schreiben. In React kann man wie gewohnt jest und react-test-renderer verwenden
    Außerdem hat die jüngste Turbo-TypeScript-Kontroverse kein Vertrauen in den langfristigen Betrieb des Hotwire-Ökosystems geschaffen
    Wir haben uns noch nicht entschieden. Dass Stimulus sich wie eine sehr Rails-typische Art anfühlt, Frontend-Code zu schreiben, ist eindeutig ein Vorteil, besonders für kleine Teams, die bereits mit Rails vertraut sind
  • „Rails ist gut, wenn man bei den Defaults bleibt, und schmerzhaft, wenn man davon abweicht“ gilt für jedes Framework
    Wenn die Anwendung ziemlich einfach ist und gut zur Arbeitsweise des Frameworks passt, ist ein Framework großartig. Wenn man eine komplexere und flexiblere Konfiguration braucht, sollte man sich Libraries ansehen
  • Ich habe das Vertrauen in die JavaScript-Integration von Rails verloren
    Inzwischen rendere ich serverseitig mit slim oder baue nur eine API und trenne das Frontend ab
    Rails hat beim Versuch, JavaScript zu machen, zu oft die Richtung gewechselt: CoffeeScript, Asset-Precompilation, webpack usw.
  • Ich würde nicht empfehlen, ein bestehendes React-Frontend gleichzeitig mit dem Rails-Upgrade selbst nach Hotwire zu migrieren. Meiner Meinung nach sollte man zuerst unabhängig auf Rails 7.1 aktualisieren
    Nebenbei: Die Art, wie Rails 7+ Single-Page-App-JavaScript handhabt, ist auch deutlich vernünftiger als früher. Im Grunde verwendet man einfach das gewünschte Build-Tool getrennt von der Rails-App
    Während der Entwicklung muss man neben rails s noch etwas wie yarn build --watch laufen lassen, aber persönlich finde ich das nicht schlecht und deutlich einfacher
    Unsere Firma entwickelt Software zur Automatisierung von Rails-Upgrades und bietet auch einen Komplettservice an, der Rails-Upgrades für euch übernimmt. Bei Interesse könnt ihr euch unter steve (at) infield.ai melden oder unter https://app.infield.ai/users/sign_up kostenlos einen Rails-Upgrade-Plan erstellen. Keine Kreditkarte erforderlich
    Mehr dazu unter https://docs.infield.ai/docs/creating-an-upgrade-path
  • Ich empfehle, https://vite-ruby.netlify.app/guide/rails.html auszuprobieren
    In meinem Fall passte es praktisch sofort als webpack-Ersatz

• Ich mag Rails und habe es seit Rails 2 immer wieder sporadisch benutzt
  Es ist ein sehr gutes Framework und für jemanden wie mich, der gelegentlich eine Website online bringen muss, wirklich der Weg des geringsten Widerstands
  Allerdings ist es mühsam, ein neues Notebook so einzurichten, dass Rails darauf läuft. Man braucht node, und damit auch npm. Als Backend-Entwickler weiß ich nicht genau, wie man node einrichtet und in welcher Reihenfolge
  Da ich das nicht oft mache, fühlt es sich jedes Mal wie ein Kampf an. Am Ende schaffe ich es zwar, bin mir aber nie sicher, warum schließlich alles zusammengepasst hat
  Es wäre schön, einen Installer zu haben, der alles Nötige auf einmal passend einrichtet, sodass rails einfach funktioniert. Der rvm-Installer richtet rails auf ruby ein, aber nicht das darunterliegende node-System

  • Ein Versionsmanager namens asdf eignet sich gut zur Verwaltung von nodejs. Ruby habe ich damit noch nicht verwendet
    https://asdf-vm.com/
  • Ich verstehe die Aussage „Als Backend-Entwickler weiß ich nicht, wie man node einrichtet“
    Node ist hauptsächlich als Frontend-Tool bekannt, und Rails verwendet es auch dafür, aber soweit ich mich erinnere, wurde Node zumindest ursprünglich entwickelt, um eine JavaScript-Runtime ins Backend zu bringen
    Auch ohne Paketmanager ist es unter Windows einfach node.exe; soweit ich weiß, lädt man npm herunter, entpackt es und fügt node und npm zur PATH-Umgebungsvariable hinzu
  • Die ganze Prämisse von Rails 7 ist gerade die Entfernung der node-Abhängigkeit
  • Ich habe noch nie mit Rails gearbeitet und frage mich deshalb, warum „Ruby on Rails“ nodejs braucht
    Und die node-Installation ist ziemlich einfach. Eigentlich zu einfach. Ich wünschte, sie wäre viel schwieriger und würde einen Hochschulabschluss erfordern
  • Die Ruby/Rails-Community gehört zu den besten und freundlichsten, die ich kenne. Aber das Schlimmste daran ist eindeutig der JavaScript-Hass
    JavaScript ist, wie alles andere, nur ein Werkzeug. Ob man es mag oder nicht, es ist ein sehr wichtiges Werkzeug, und ob man es mag oder nicht, es wird noch lange bleiben
    Wenn man mit etwas Offenheit zumindest die Grundlagen lernt, wird die Arbeit leichter

• Ich hoffe, dass Rails + HTMX und der Ansatz, nur auf sehr interaktiven Seiten etwas JavaScript einzustreuen, wieder aufleben
  Rails zusammen mit Slim/HAML zu verwenden, macht wirklich Spaß. Wenn man möchte, kann man mit Libraries wie ViewComponents Partial Rendering einfacher machen. Fügt man Web Components hinzu, kann man ziemlich interaktive Seiten bauen, und wenn es auf einer bestimmten Seite wirklich nötig ist, kann man auch React verwenden
  HATEOAS reduziert die Komplexität von Anwendungen erheblich. Wenn man trotzdem eine API braucht, ist es sehr einfach, auf unterschiedliche MIME-Typen zu antworten, und wenn man möchte, kann man denselben Endpoint teilen
  Meiner Erfahrung nach brauchen die meisten Anwendungen, die React verwenden, eigentlich überhaupt kein React. Sie verwenden React wegen ein paar Popup-Menüs
  Wenn also große Apps ohne React oder mit nur sehr wenig React auftauchen, hoffe ich, dass manche Leute erkennen, wie unnötig komplex unsere Anwendungen heute sind
  Allerdings sehe ich schon jetzt Aussagen wie „Alle verwenden React, also müssen wir auf React umstellen“. Zum Seufzen
  Träumen darf man ja

• Die offizielle Ankündigung gibt es hier: https://rubyonrails.org/2023/10/5/Rails-7-1-0-has-been-released
  Sie enthält etwas mehr Details auf hoher Ebene, und ich freue mich darauf, einige der neuen Änderungen auszuprobieren. Besonders die neuen asynchronen Query-Methoden dürften für schnelle Performance-Verbesserungen ziemlich nützlich sein.

• Rails im Backend bekommt nicht die Anerkennung, die es verdient
  Die Frontend-Seite war allerdings sehr lange ein Durcheinander

  • Ich widerspreche nicht, dass „die Frontend-Seite lange ein Durcheinander war“, aber Frontend an sich war ebenfalls lange ein Durcheinander
    Jetzt macht die Arbeit mit Rails 7.1 + Hotwired + Importmaps Spaß
    Allerdings musste man warten, bis Browser mindestens ES6 und Import Maps gut unterstützen
    Dem Datum dieses Artikels nach wurde am 28. März 2023 angekündigt, dass importmaps in allen modernen Browsern nutzbar sind: https://web.dev/import-maps-in-all-modern-browsers/
    Bis dahin gab es also keine Möglichkeit, Webpack, Yarn und andere JavaScript-Hilfswerkzeuge zu vermeiden
    Jetzt haben wir importmaps, und die ES6-Unterstützung der Browser ist gut genug, siehe https://caniuse.com/?search=es6, sodass man modernes JavaScript fast ohne zusätzliche Tools nutzen kann
  • Einverstanden. Was sind hier die Optionen? Rails im API-only mode?
  • Ich mag die neuen Hotwire-Funktionen. Mich würde interessieren, was dir am Frontend nicht gefällt

• Vor ein paar Wochen scherzte ein Freund: „Wenn ein Rails-Release angekündigt wird und du keinen Upgrade-PR aufmachst, ist es dann wirklich passiert?“
  Nun, jetzt ist es Zeit, den PR aufzumachen. Selbst wenn er sich hinter dem seit Monaten wartenden 7.0-PR einreihen muss

• Meiner Erfahrung nach tun sich viele Teams schwer, mit ActiveRecord eine saubere Codebasis aufzubauen

• Bitte nicht hauen, aber ich nutze noch Rails 4.2 und bin zufrieden damit
  Es bietet alles, was ich für Backend-SaaS-Arbeiten ohne oder mit wenig JavaScript brauche, die ich selbst mache oder für B2B-Unternehmen erledige, und es läuft auch auf schwachen VPS
  Falls jemand Zeit zum Antworten hat: Mich würde interessieren, warum ich upgraden sollte

  • Ich nutze auch eine ältere Version. Zuerst sollte man prüfen, ob man zumindest auf die neuesten Patch-/Minor-Versionen aktualisieren kann
    Das Kernproblem bei alten Versionen sind Schwachstellen in angebundenen Gems. Zum Beispiel lässt sich nokogiri eventuell nicht ohne ein Major-Upgrade von Rails aktualisieren
    Allerdings machen die meisten Apps zum Beispiel kein komplexes XML-Parsing, daher treffen viele Schwachstellen nicht zu. Deshalb braucht es etwas Wartung, um zu prüfen, ob man sicher ist. Häufig fügt man auch Monkey-Patches ein, um Bugs zu verhindern
    Ein Upgrade verbessert die Sicherheit und reduziert den Wartungsaufwand. Aber man muss auch die Kosten ständiger Upgrades berücksichtigen. Ein weiterer Faktor ist, dass neuere Versionen Unterstützung für schnelleres Ruby bekommen können
    Normalerweise verwende ich beim Erstellen einer Rails-App das neueste Release, aber danach aktualisiere ich Rails-Versionen nicht, sofern die App nicht stark genutzt wird oder so alt ist, dass auf neuen Systemen etwas nicht mehr funktioniert
  • Wegen der Sicherheit solltest du upgraden