© Denys Bilytskyi, 123RF

Ruby on Rails 5.2 soll, wie alle Versionen der vergangenen Jahre, zeitgleich zur Railsconf erscheinen, die Mitte April 2018 in Pittsburgh (USA) stattfindet. Während sich für alte Rails-Anwendungen nicht besonders viel ändert, gibt es für neue ein paar erwähnenswerte Ergänzungen.

Ruby on Rails 5.1 (kurz RoR, [1]) führte Secrets ein. Der Mechanismus sollte dafür sorgen, dass ein Programmierteam Passwörter oder API-Keys verschlüsselt in einem öffentlichen Repository ablegen kann. Die Resonanz der Community auf dieses Feature erwies sich allerdings als gemischt. Viele fanden es von Anfang an unnütz, weil die Team-Mitglieder ja trotzdem einen geheimen Verschlüsselungskey austauschen müssen. Andere fanden es praktisch, aber noch ein wenig zu umständlich einzurichten und zu benutzen.

Zumindest für die letztgenannte Gruppe soll Rails 5.2 (Abbildung 1) Gutes bringen: Die Entwickler haben Secrets abgeschafft und ersetzen sie durch einfachere Credentials. Dadurch erzeugt RoR automatisch einen zentralen Masterkey und legt ihn in der Datei »config/master.key« ab. Diese Datei darf natürlich nie in einem Repository landen, weshalb sie auch standardmäßig in der Datei ».gitignore« eingetragen ist. Die Credentials bearbeitet der User auf der Kommandozeile mit dem Befehl »EDITOR=vim rails credentials:edit« im Yaml-Format. Ein Beispiel zeigt Listing 1.

01 # aws:
02 # access_key_id: 123
03 # secret_access_key: 345
04 # Used as the base secret for all MessageVerifiers in Rails,
05 # including the one protecting cookies.
06
07 secret_key_base: 9846dad34a3168?68d634f
08 foobar: test

Über die Rails-Applikation und die Konsole lassen sich die Credentials dann wie in Listing 2 abrufen, wobei der Name der Anwendung im Beispiel »Shop« lautet.

01 $ rails console
02 Running via Spring preloader in process 19662
03 Loading production environment (Rails 5.2.0)
04 >> Shop::Application.credentials.foobar
05 => "test"
06 >> exit

Überraschung: Active Storage

Wie die meisten Rails-Features schwappte auch das neue Active Storage von der vom Rails-Erfinder David Heinemeier Hansson geleiteten Firma Basecamp rüber in das Toolset. Dabei handelt es sich um ein Framework, um Dateien über den Webbrowser hochzuladen und dann mit Hilfe von Rails zu verwalten. Das soll sowohl für den eigenen Server wie auch für Cloudserver und -dienste (beispielsweise Amazon S3, Google Cloud Storage und Microsoft Azure Cloud File Storage) möglich sein. Grafiken verarbeitet Active Storage dabei auch selbstständig. Ein anschauliches Beispiel ist zum Beispiel das automatische Erzeugen eines Vorschaubilds für ein Avatar-Bild.

Abbildung 1: Ruby on Rails 5.2 lässt sich bereits als Release Candidate ausprobieren.

Die Einführung von Active Storage hat jedoch einige Rails-Entwickler überrascht. Mit Carrierwave [2] und Paperclip [3] gibt es bereits mindestens zwei seit Jahren etablierte Lösungen für das File-Upload-Problem. Warum also das Rad neu erfinden?

Die Antwort darauf liegt in einer Zusammenlegung von Funktionen an zentraler Stelle und einer neuen Funktionalität: Mit Active Storage laden Anwender Dateien vom Browser aus direkt per Javascript zum Cloudanbieter hoch. Sie müssen nicht mehr über den Rails-Server laufen, den solche Uploads unnötigerweise lange blockieren. Diese Blockade erwies sich bei vielen Rails-Applikationen auf Cloud-Hosting-Diensten wie Heroku als Problem, da die meist nach 30 Sekunden die Verbindung zum Client kappen.

Sicher lässt sich darüber streiten, ob eine File-Upload-Funktionalität ein zentraler Bestandteil von Ruby on Rails sein sollte und ob sich Active Storage nicht besser als ein normales externes Gem eignen würde. Aber auf jeden Fall macht Active Storage das Hochladen von Dateien für Programmierer und Anwender einfacher.

Bootsnap

Das vom Rails-Großanwender Shopify erstellte Gem Bootsnap [4] setzt Rails 5.2 jetzt standardmäßig ein. Das reduziert die Startzeit einer Rails-Applikation im Schnitt um 50 Prozent. Shopify berichtet für den eigenen Monolithen gar von einer Reduktion um 75 Prozent oder konkreter von stattlichen 25 auf 6,5 Sekunden.

Content Security Policy

Rails bietet schon lange einen eingebauten XSS- und CSRF-Schutz (Cross Site Request Forgery). Version 5.2 will ihn um eine neue Domain Specific Language (DSL) erweitern, die Zugriffsrechte auf Ressourcen-Basis erlaubt. Das ist nicht trivial und kann Anfängern schon mal Kopfschmerzen bereiten. So funktioniert bei einer frischen Rails-Applikation Action Cable nicht im Development-Modus. Das muss der Admin per »p.connect_src :self, :https, ‘ws://localhost:3000’« in der »config/initializers/content_security_policy.rb« manuell freischalten.

HTTP/2 Early Hints

HTTP/2 verbreitet sich immer mehr. Im Zuge dessen wird auch der Wunsch nach dem Push-Feature in der Rails-Community immer lauter. Im Gegensatz zu HTTP/1.1, bei dem ein Webclient nur Dateien vom Webserver via HTTP GET holen kann, bietet HTTP/2 auch die Möglichkeit, dass der Webserver Dateien aktiv und ungefragt an den Webbrowser ausliefert. Das steigert auch die Webperformance einer Webanwendung.

Rails-Core-Mitglied Aaron Patterson hat dies mit Hilfe von Eileen Uchitelle in der neuen Rails-Version eingebaut. Dadurch lässt sich der über der Rails-Schicht liegende Webserver vom Rails-Framework aus instruieren, Stylsheets und Javascript-Assets zum Webbrowser zu pushen.

In diesem Bereich dürfte sich bei zukünftigen Rails-Versionen bestimmt noch einiges bewegen. Bislang baut das Rails-Asset-Management noch immer auf der für HTTP/1.1 richtigen Grundidee auf, lieber eine große als viele kleine Dateien zu verschicken. Dank HTTP/2 ließen sich aber auch viele kleine Dateien senden.

Redis Cache Store

Der neue Redis Cache Store stammt auch aus dem Basecamp-Labor. Dort hat Jeremy Daer mit dem neuen Gem eine sehr stabile und schnelle Möglichkeit geschaffen, Redis als Cache im Distributed-Modus anzusprechen. Dadurch lassen sich Daten auf verschiedenen Redis-Servern verteilt abspeichern.

Wer beim Fragment Caching auf die Russian-Doll-Strategie setzt, erhält übrigens dank Key Recycling und Compression per Default und ohne zusätzliche Arbeit eine verbesserte Cache-Lebensdauer.

Zusammenfassung

Rails 5.2 gilt als Minor-Update und sollte sich problemlos und ohne großen Aufwand in bestehende Rails-Applikationen integrieren lassen. Mit der neuen Version kündigt sich keine Revolution an, sondern ein handliches Set solider Verbesserungen. Für die meisten Rails-User dürfte Active Storage die größte Veränderung und Optimierung sein.