© Fotograf, 123RF

Läuft alles nach Plan, setzen die Ruby-on-Rails-Macher Ende April 2017 die neue Version 5.1 aufs Gleis. Die liebt Javascript und hat unter anderem den flinken Javascript-Paketmanager Yarn an Bord. Zudem kann sie dank eigener Javascript-Bibliothek erstmals auf Jquery als Default-Option verzichten.

Ende April, zur Rails Conf 2017 [1], wollen die Macher des Webframeworks Ruby on Rails (RoR) Version 5.1 veröffentlichen. Galt zur 5.0er Release noch Action Cable zur Websocket-Nutzung als große Innovation, geht Rails nun einen Schritt vorwärts und bindet Javascript besser in die Entwicklung ein. Größte Neuerung von RoR 5.1 ist die Integration des Javascript-Paketmanagers Yarn [2]. Dass der im Hintergrund die Fäden zieht, dürfte Umsteigern schnell auffallen. Warteten sie beim Vorgänger NPM noch eine gefühlte Ewigkeit auf den Download von Paketen, puffert Yarn diese jetzt lokal. Das dürfte insbesondere Bahncard-100-Vielfahrer erfreuen.

Ein Paukenschlag beim Thema Javascript ist der Verzicht auf Jquery [3] in der Standardversion. Rails deckt die absolut notwendigen Funktionen jetzt mit einer platzsparenden eigenen Javascript-Bibliothek ab. Das spart beim initialen Download im Schnitt rund 100 KByte und ist somit wichtig für eine gute Webperformance. Wer weiterhin mit Jquery arbeiten will (das dürften die meisten sein), kann das mit Yarn einfach installieren: »bin/yarn add jquery«. Danach bindet der User Jquery noch mit der Zeile »//= require jquery« in der Datei »app/assets/javascripts/application.js« ein, den Rest übernimmt die Asset-Pipeline.

Fans von Webpack dürften sich im Übrigen darüber freuen, dass mit dem Webpacker Gem und dem Schalter »–webpack« nun standardmäßig eine einfache Nutzung von Webpack bereitsteht.

Wer Rails als reinen API-Server benötigt, kann eine neue Applikation mit »rails new my_API –api« starten und erhält anschließend ein auf das API-Minimum reduziertes System. Gerade für Single-Page-Javascript-Applikationen ist dies recht praktisch.

Systemtests mit Chrome

Rails-Erfinder David Heinemeier Hansson sorgte schon in der Vergangenheit beim Thema Testing oft für Aufsehen. Ursprünglich war Rails das erste populäre Framework, das stark auf Test Driven Development setzte. Im Jahr 2014 philosophierte er [6] lange darüber, dass Unit Tests nicht die gleiche Priorität besitzen wie Integration Tests (ein Punkt, über den sich trefflich streiten lässt). Das Problem dieser Tests ist aber, dass sie moderne Javascript-Komponenten der Applikation nicht abdecken. Dies muss im Browser geschehen.

Für solche Systemtests gab es schon lange das Capybara-Gem, aber erst Rails 5.1 integriert es als festen Bestandteil in das Framework. Der Test startet automatisch einen Chrome-Browser, in dem die Tests stattfinden. Treten Fehler auf, sieht der Entwickler einen Screenshot des Browserfensters. Diese Tests haben natürlich einen Preis: Zeit. Ein Systemtest im Browser dauert immer deutlich länger.

Schlüssel meistern

Nicht selten hosten Entwicklerteams ihre Rails-Applikationen auf Github, Gitlab oder in anderen bekannten Repositories, die bei Open-Source-Projekten auch gleich eine Code-Einsicht erlauben. Was für den Quellcode Sinn ergibt, ist für Datenbankpasswörter oder API-Keys eher unerwünscht. Traditionell landen solche Passwörter nicht im Repository, sondern der Server speichert sie in Umgebungsvariablen ab, Stichwort »env«.

Logischerweise ist das sehr aufwändig zu administrieren. Über »rails secrets:setup« generiert ein Entwickler nun einen Masterkey, um solche Passwörter zu verschlüsseln. So lassen sich alle Passwörter und API-Keys im öffentlichen Raum ablegen und auf dem Server oder dem Entwicklersystem mit dem zentralen Masterkey dechiffrieren.

Große Integers für IDs

Im Jahr 2009 hatte Twitter (damals noch eine Ruby-on-Rails-Applikation) ein Problem: Die Datenbank-IDs für einzelne Tweets waren 32-Bit-Integers – und der Tweet Nummer 2 147 483 647 kündigte sich am Horizont an. Die Umstellung auf 64-Bit-Integers brachte dem Kurznachrichtendienst damals deutlich mehr Luft (und zwar für 9 223 372 036 854 775 807 Tweets). Kaum acht Jahre später kommt jetzt auch der Rest der Ruby-on-Rails-Welt in den Genuss von »bigint«, das ein Standard der Version 5.1 wird.

Daneben gibt es in der Rails-Community eine Diskussion, auf UUIDs zu wechseln statt Integers hochzuzählen. Eine Umstellung wäre mit einem Gem heute sogar recht einfach möglich. Da aber die Grenze von »bigint« so hoch ist und ein Großteil der Anwender den traditionellen Weg bevorzugt, bleibt es zumindest vorerst bei den Integers.

Ruby 2.4

Rails 5.1 unterstützt das im Dezember 2016 veröffentlichte Ruby 2.4 und bekommt damit kostenfrei und ohne Nachteile eine bessere Performance. Mit 2.4 gehört der Unterschied von Fixnum und Bignum der Vergangenheit an. Es gibt jetzt nur noch Integers. Ruby kümmert sich selbstständig um die Optimierung.

Lohnt der Umstieg?

Gott sei Dank sind die Zeiten vorbei, in denen das Upgrade einer Rails-Version auf eine neuere einem Martyrium gleichkam. Der Umstieg von Rails 5.0 auf 5.1 ist völlig schmerzfrei und auch ein Upgrade von 4.2 auf 5.1 dürfte keine Kopfschmerzen bereiten.

Die Frage lautet eher, ob sich der Umstieg lohnt. Das Ökosystem rund um Rails ist viel größer als etwa das Phoenix-Framework, das in letzter Zeit einige ehemalige RoR-Entwickler anzog (siehe Kasten “Phoenix im Anflug”). Der Weg aus einer objektorientierten Welt in eine funktionale Programmiersprache ist allerdings steinig und steil. Die meisten Umsteiger nehmen diese Schmerzen wegen der Geschwindigkeit und des Hot Deployment in Kauf. Die Entwicklungszeit einer Applikation fällt zudem bei beiden Frameworks identisch aus.

Phoenix im Anflug

Seit einiger Zeit wandern prominente Ruby-on-Rails-Entwickler zum Phoenix-Framework [4] ab. Dies setzt auf die funktionale Programmiersprache Elixir [5], die ihrerseits auf der Erlang Virtual Machine (Beam) fußt.

Der ehemalige Ruby-on-Rails-Entwickler José Valim hatte Elixir 2012 erfunden. Aus den Concurrency-Problemen mit Ruby entstand seine Idee zu der funktionalen Programmiersprache. Auch Chris McCord (Abbildung 1) war erst ein aktiver und bekannter Ruby-on-Rails-Entwickler. Um die Performanceprobleme von Rails zu umgehen, übernahm er dann einige Ideen von Rails und entwickelte mit Hilfe von Elixir ein neues Framework mit dem Namen Phoenix. Das gewann mit José Valim sehr schnell ein neues Core-Team-Mitglied und erschien im Herbst 2015 in Version 1.0. Mittlerweile hat Phoenix die Sichtbarkeit für Elixir ähnlich erhöht, wie Ruby on Rails es einst für Ruby tat.

Abbildung 1: Chris McCord stellt das Phoenix-Framework in Version 1.3 vor. Das schart einige ehemalige RoR-Entwickler um sich, setzt aber nicht mehr auf Ruby, sondern auf die funktionale Sprache Elixir.

Phoenix lockt unter anderem mit einer optimierten Testbarkeit und Performance, der Stabilität von Beam und einer besseren vertikalen Skalierbarkeit. Admins schalten sehr einfach mehrere Server zusammen. Auf jedem Server verteilt Beam automatisch die Last auf andere Server im Cluster. Das Gleiche gilt für Hot Deployments. Phoenix macht es möglich, eine neue Softwareversion ohne Downtime in Beam zu laden.

Für RoR sprechen indes Hunderttausende fertige Gems, die Entwicklern viel Programmierarbeit abnehmen. Es gibt außerdem diverse Bücher und Screencasts zum Lernen und es ist vergleichsweise einfach, Rails-Entwickler zu finden und einzustellen.

Wer auf der grünen Wiese anfängt, der sollte einen Blick auf Phoenix werfen. Wer bereits ein Rails-Projekt betreut, für den ist der Umstieg aufwändig. Wenn Performance keine primäre Rolle spielt und bei Deployments eine kurze Downtime akzeptabel ist, dann bleibt Rails – wegen des größeren Ökosystems – weiterhin eine sehr gute Wahl.