Rails für alles – die Leistungsfähigkeit von Rails für jedes Projekt

• Rails 8 ist für kleine Projekte und Einzelentwickler äußerst nützlich
• Mit dem aktuellen Startleitfaden lässt sich eine Produktionsanwendung mühelos erstellen
• Durch die Verbesserungen in SQLite ist eine starke Datenbankumgebung ohne zusätzliche Server möglich
• Mit den integrierten Funktionen für Continuous Integration (CI) und Authentifizierungs-Generator werden die Entwicklungseffizienz und Sicherheit verbessert
• Durch den einfachen Bereitstellungsweg über Kamal lässt sich der Betrieb von Services schnell und sicher realisieren

---

Überblick

• Basierend auf der Erfahrung mit Rails 8 ist es ein ausgezeichnetes Web-Framework für kleine Projekte oder Einzelentwickler
• Über schnelles Bereitstellen, effizientes Deployment und eingebaute Module werden deutliche Produktivitätsvorteile gegenüber konkurrierenden Frameworks sichtbar

Qualität des aktuellen Guides

• Der aktuelle Guide Getting Started with Rails ist so aufgebaut, dass auch Einsteiger eine Produktionsanwendung erstellen können
• Auch wenn die Ruby-Installation noch komplex ist, kann man mit der Anleitung eine robuste Anwendung mit Authentifizierung, Caching, Rich Text, CI und Datenbank aufbauen
• Seine Stärke liegt nicht in einem simplen ‚Hello World‘, sondern in Grundbausteinen und Funktionen auf realem Service-Niveau
• Für Einsteiger, die mit Rails nicht vertraut sind, ist es ein optimaler Einstiegspunkt

SQLite reicht

• SQLite ist grundsätzlich ein starkes Werkzeug, aber es war bisher nicht einfach, es für Produktionszwecke bereitzustellen
• Früher waren zusätzliche Schritte wie das Installieren weiterer Gems nötig; mit Rails 8 ist es jetzt ohne zusätzlichen Aufwand stabil in der Produktionsumgebung nutzbar
• Weder PostgreSQL noch ein zusätzlicher Server sind nötig, und mit Solid Cache wird auch kein Redis-Server benötigt
• Mit nur Rails und SQLite lässt sich ein Service betreiben, wodurch einfache Einrichtung und Betrieb sowie Kostenersparnis optimiert werden

Einfache Continuous Integration (CI)

• In Rails 8 ist eine standardmäßig eingebundene CI-Konfiguration enthalten, sodass bereits nach dem ersten Commit eine CI-Fehlermeldung eintreffen kann
• GitHub Actions ist ohne zusätzliche Konfiguration integriert und es stehen 2.000 kostenlose Ausführungsminuten pro Monat zur Verfügung
• Für Einzelentwickler ist das ein ziemlich großzügiges Kontingent

Einführung des Authentifizierungs-Generators

• Früher galten Authentifizierungs-Gems wie Devise als stark, wirkten jedoch aufgrund ihrer Komplexität bei der Einrichtung für Einsteiger oft schwierig
• Rails 8 führt einen einfachen Authentifizierungs-Generator ein, mit dem man über die Konsole einfach bestehende Nutzer hinzufügen und so den Login-Fluss umsetzen kann
• Der generierte Code ist einfach und leicht lesbar, sodass ihn auch Einsteiger gut verstehen können

Schnelle und einfache Bereitstellung mit Kamal

• Kamal übernimmt den Deploy-Prozess; mit nur minimalen Anpassungen an deploy.yml und der Befolgung der Anleitung kann die App sofort in einer SSL-Umgebung gestartet werden
• Es ist ein schnelleres Web-App-Deployment-Erlebnis als das Anbinden von SSL an GitHub Pages
• Die Kombination aus CI und einfacher Bereitstellung ist ein besonders deutlicher Vorteil von Rails 8
• Selbst allein mit dem Einstiegsleitfaden lässt sich eine Entwicklung auf Basis von aktuellem Best Practice erleben

Fazit

• Rails ist weiterhin ein starkes und sich weiterentwickelndes Framework
• Wenn Sie dieses Jahr ein neues Projekt planen, lohnt es sich, mit Rails 8 zu entwickeln

[aer0700]

In letzter Zeit sehe ich so viele Beiträge zu SQLite, dass es inzwischen schon fast alles auf SQLite geworden ist.

Müsste man das als eine Wiederbelebung des Klas-sischen bezeichnen?

[GN⁺]

Hacker News Kommentar

• Ich arbeite zurzeit mit dem Spring Boot-/ Micronaut-Stack an Apps und habe auch ein React-Frontend eingesetzt. Mir gefällt immer mehr der Omakase-Ansatz von Rails (alles vorgefertigt). Selbst einfache Sachen wie Formularvalidierung aus dem Backend oder Flash-Nachrichten löst das Framework nicht automatisch; man muss sie entweder selbst bauen oder bei Drittanbietern suchen. Rails löst rund 90 % der typischen Web-App-Probleme schon vorweg. Es ist nicht perfekt, aber in den meisten Fällen reicht die Standardfunktionalität aus und man kann sie bei Bedarf ersetzen.
  • Bei Spring Boot ist die Formularvalidierung beinahe vollständig standardmäßig enthalten und direkt über Annotationen nutzbar.
• Für mich sind Rails und Django beide starke Frameworks. Ich habe sogar missionkritische Apps in Python gebaut. Bei großen Monolithen würde ich aber lieber auf Go wechseln, weil ich dessen Typsystem und Nebenläufigkeit als stärker empfinde. Das Problem ist, dass die Go-Community kein Framework-Ökosystem wie Rails oder Django aufgebaut hat. Für Netzwerkwerkzeuge oder CLIs ist Go top, für schnell aufzubauende Full-Stack-Web-Apps wähle ich aber noch immer Rails oder Django. Deshalb kann ich kaum glauben, dass „Rails vorbei“ ist.
  • Mit Tools wie ogen kann man aus einem einzigen OpenAPI-Dokument fast alles automatisch erzeugen: statische Router, Request-/Response-Validierung, Prometheus-Monitoring, OpenTelemetry-Tracing usw. Auch Client- und Webhook-Code wird generiert; für Authentifizierung ergänzt man nur eine Funktion. Kombiniert mit sqlc und SQLites pragma user_version werden typsicherer DB-Code und Migrationen einfacher. Für SQLite reicht es bei mir oft, in main.go zwei import-Zeilen einzufügen. Mit der Go-Standardvorlage reicht die Frontend-Textverarbeitung, und mit embed bindet man statische Assets leicht ins Binary ein. Das Deployment ist ebenfalls simpel: go build und dann nur das Binary verschieben. Die Code-Generator-Tools machen die Go-Backend-Entwicklung dadurch sehr schnell und bequem.
  • Ich wollte auch einen vollständig statisch typisierten Stack, aber für mich war klar ASP.NET statt Go oder Rust. Microsoft macht viel Werbung für neue Produkte (z. B. Aspire.NET), aber in der Praxis ist .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) wirklich batteries included und sehr zuverlässig. Der Wechsel erfordert etwas ein OOP- und DI-Denken, ist aber für erfahrene Entwickler kein großes Problem.
  • Das Problem in der Go-Welt ist nicht nur eine anti-Framework-Mentalität, sondern auch eine anti-moderne-Funktionen-Haltung. Java, Kotlin, Scala, C#, F# usw. sind ebenfalls gut für Netzwerk-Tools oder CLI-Entwicklung. Heutzutage gibt es bei Java AOT übrigens keine großen kommerziellen Lizenzfragen, und .NET ist nicht mehr an Windows gebunden.
  • Ich würde Encore empfehlen. Gerade bei PaaS-Integration (wie bei der Kombination NextJS + Vercel) ist es sehr stark. Es passt etwas anders zu den Kernprinzipien von Go, aber für kleine Teams oder Ein-Personen-Teams ist es eine sehr gute Wahl. Bei Bedarf kann man es per BYOC selbst deployen oder mit der stdlib ein eigenes API-Layer betreiben. Für das Frontend braucht man NextJS oder Remix/RR7, aber durch das automatisch generierte TypeScript-Client-SDK ist die Integration extrem einfach. Außerdem bietet Encore einen großen Vorteil: Vercel-PR-Integration.
  • In Go kommt mir am ehesten ein Django-ähnliches Erlebnis mit beego vor. Es ist okay, aber noch nicht so reif, dass man von Rails- oder Django-Niveau sprechen kann.
  • Ich habe gerade ein Go-Projekt am Laufen und bin mit dem sauber geschriebenen Code sehr zufrieden. KI hilft dabei, die Einstiegshürden für Frameworks deutlich zu senken. Trotzdem empfinde ich kundennahe Services mit Rails, interne Tools und Datenarbeiten mit Django intuitiver.
  • Mit Sorbet lässt sich Ruby typisieren, und die auf Fiber basierende Nebenläufigkeitsfunktion ist fast fertig. Ein neuer Webserver namens Falcon, gebaut auf Fiber, ist im Entstehen. Er ist noch nicht so weit wie Puma, aber wird wohl bald produktiv einsetzbar sein.
  • Der Autor von Stanza hat einen Beitrag geschrieben, in dem er beschreibt, dass eine starke Framework-Lösung wie Rails gewisse Voraussetzungen in der Sprache selbst braucht. Dass Go oder Java keine vergleichbaren Frameworks haben, ist ein Zusammenspiel aus Sprach- und Programmiergrenzen.
  • Go war ursprünglich gar nicht für einen Full-Stack-Framework-Ansatz wie Rails oder Django gedacht.
  • Node/Express eignet sich eher für Pico-Services für lokale Entwickler, während ASP.NET WebAPI/MVC für mich das ideale Backend ist.
  • goravel dev ist ebenfalls einen Versuch wert.
• Wenn man die Rails Guides von vorne bis hinten durchgeht, kann man sofort einen echten Service mit Authentifizierung, Caching, Rich Text, CI und DB aufsetzen. Das passt für große Dienste wie GitHub oder Airbnb, in einem frühen Startup wäre es aber unter Umständen Zeitverschwendung, von Anfang an alles hinzuzufügen, was Devise-Auth, Turbo, Tests etc. bieten. Turbo macht Seiten schneller, kann aber mit Devise kollidieren und so die Entwicklungszeit erhöhen. In der frühen Idee-validierenden Phase vor dem Launch ist es vertretbar, Tests und CI (außer für Banking-/Healthcare-Apps) zurückzustellen. Wichtig ist, nicht dem Default-Bias zu erliegen („etwas ist da, also nehmen wir es“) und klar „Nicht jetzt“ zu sagen.
  • Wenn man eine SaaS-App plant, spart man mit Rails-spezifischen Templates wie Jumpstart Pro oder Bullet Train gleich mehrere Monate. Payment, Authentifizierung und Co. sind enthalten, und Erweiterungen sind einfach.
  • Ich bin mit der Meinung zu Tests nicht einverstanden. Selbst bei kleinen Apps spart Testcode eher Zeit. CI ist meist in einer rund zwanzig Zeilen Datei erledigt, und ich habe es in alten Projekten oft einfach kopiert.
  • CI ist ein Beschleuniger der Entwicklung. Es lohnt sich, es früh im Projekt zu ergänzen.
  • Ich frage mich, wann genau man von Flask/Express/Sinatra/Gradio/Hono auf Rails wechseln sollte.
• Das aktuelle Rails macht sich wirklich toll, ich sehe es deutlich glatter als früher. Ich habe seit Rails 2.3 zwölf Jahre lang verschiedene Apps gewartet, und jetzt wirkt Rails wie ein völlig anderes evolutionsfähiges Pokémon. Selbst der Rails Upgrade Guide ist so gut aufbereitet, dass man ohne große Refaktorisierungen sauber upgraden konnte. Nicht vollständig rückwärtskompatibel, aber dafür ist die Änderung klar dokumentiert. Dank ActiveStorage hat sich der Dateianhang stark verbessert; der Wechsel von Webpacker war zwar etwas mühsam, aber mit Import Maps scheint es jetzt leichter zu sein. Dieses Jahr plane ich auf 8.1 zu updaten.
  • Vor vier Jahren habe ich mich für einen Kunden mit kleinem Budget (zu Ruby-2.3-Zeiten) entschieden, den Support einer alten Rails-App trotz Gehaltskürzung zu übernehmen. Ich bin sehr zufrieden, weil Upgrades und Feature-Erweiterungen dann wirklich einfach wurden.
• Ich entwickle ein Open-Source-Rails-Projekt allein und unterstütze damit etwa 120.000 Nutzer pro Monat, daher stimme ich den Aussagen im Beitrag stark zu. Ein zusätzlicher Pluspunkt ist, dass ActiveStorage für Dateianhänge wirklich großartig ist. Meistens nutze ich Dokku für Deployment, aber ich freue mich darauf, Kamal auszuprobieren. Rails entwickelt sich weiter und Ruby wird immer schneller.
  • Wenn du Dokku magst, wäre ich neugierig, ob du schon Cloud Native Buildpacks ausprobiert hast. Damit lassen sich direkt OCI-Images erzeugen.
• Ruby zu lernen war für mich nicht zentral in der Webentwicklung; im Grunde kannte ich nur Django. Ich frage mich, welche Unterschiede es zwischen beiden Frameworks gibt.
  • Ich habe in beiden Ökosystemen viel Erfahrung (kürzlich etwas weniger mit Rails). Django ist eng mit Python, Rails mit Ruby/Gems verknüpft, daher ist der Einfluss des Ökosystems groß. Django Admin CMS ist eindeutig stärker als bei Rails, viele Teams bauen intern ihr CMS komplett mit Django. Rails hat ein riesiges Scaffolding-CLI, wodurch CRUD-Funktionen extrem schnell entstehen. Rails ist stärker abstrahierend und gibt Struktur/Architektur weitgehend vor; in Django muss man viel mehr selbst wählen. Rails ist stringenter bei DRY und Wiederverwendung von Code. Wer die Python-Intuition betont, empfindet die Rails-„Magic“ als aufdringlich, während Rails-Leute Python als zu repetitiv empfinden können. Im Kern sind das zwei unterschiedliche Stile.
  • Würde ich eine Web-App für Endnutzer bauen, nehme ich Rails zuerst. Ich finde Scaffolding bis zum Marktlaunch einfacher (auch wenn ich keine große-Service-Erfahrung habe). Für interne Tools, Datenarbeit oder Geodaten wäre Python/Django besser.
  • Der größte Unterschied ist Python vs. Ruby. Das Python-Ökosystem ist enorm groß, Django bringt Authentifizierung und ein eingebautes Admin-Panel mit.
  • In Testumgebungen fand ich Rails als besser; Rails bietet CI-Setup und automatische Testcode-Generierung.
  • Aus eigener Erfahrung ist Django Admin deutlich flexibler und einfacher zu bedienen als Ruby-Pendants. Dafür sind Tests und Routing in Rails besser, und auch die Konventionen sind strenger. Ich mag ActiveRecord+arel lieber als das Django-ORM (persönlich macht das Schreiben von Ruby-Code mehr Spaß als Python).
  • Ruby ist nicht schwer zu lernen, und Rails gibt deutlich mehr Struktur und Konventionen vor als Django.
• Viele Leute haben zu Rails fast eine Art „verliebt“-Gefühl; so stark fühle ich das nicht und beneide sie manchmal. Jedes Framework hat seine Fans, aber die Rails-Welle wirkt einfach etwas besonderer.
  • Auch wenn mir einige Rails-Konventionen unbequem sind, ist es in JavaScript-Backends fast unmöglich, eine ähnliche Produktivität zu erreichen. Umgekehrt sieht man in Rails-Projekten oft, dass Kernfunktionen von Rails (z. B. Active Job) grundlos neu implementiert werden. Der Konventionen zu folgen ist oft effizienter.
• Ich habe SQLite in Production eingesetzt und es wurde klar: Bei Migrationen gibt es Ärger. Wenn man zu einer bestehenden Spalte eine NOT NULL-Constraint hinzufügen will, muss man die ganze Tabelle über eine temporäre Tabelle neu schreiben.
  • SQLite kennt weder ADD CONSTRAINT noch PL-Sprachen oder einfache Stored Procedures, daher braucht man in statisch typisierten Sprachen ständig den Umweg über die Host-Sprache – das ist umständlich.
  • Ich sehe Postgres als Top-Kandidaten und lasse es nicht so leicht fallen. Aber es ist ein guter Fortschritt, dass sqlite3 in Rails jetzt als echte Erstklasse-Option geführt wird.
  • Rails empfiehlt zwar, SQLite ersetze Redis, doch praktisch ist es nur für den Start kleiner Services geeignet. Wenn ein späterer Umzug auf eine andere DB wahrscheinlich ist, würde ich nicht mit SQLite starten — die Migration ist fast immer schmerzhaft.
  • Mit ActiveRecord-Validierungen lässt sich in Rails vieles lösen, aber es gibt Grenzen bei der Abbildung echter Datenbankconstraints.
• Der Ruby-Installationsleitfaden ist ziemlich komplex. Beim Neuaufsetzen eines Jekyll-Blogs nach 15 Jahren hatte ich bei Gems auch Mühe. Teilweise war das meine Schuld, aber es wäre schöner, wenn es einfacher wäre. Trotzdem war es ein guter Anlass, Ruby wieder in die Hand zu nehmen.
  • Setup sollte für jeden einfach sein. Ich habe Jekyll zügig gelernt, weil Ruby und RubyGems ohnehin schon in meiner Umgebung vorhanden waren.
• Wenn du nur SQLite nutzen willst, lohnt sich ein Blick auf litestack. Ich habe es noch nicht selbst eingesetzt, plane aber, ein persönliches Projekt von Postgres auf litestack zu wechseln. Die Benchmark-Leistung ist wirklich beeindruckend.
  • Rails 8 hat SQLite deutlich erweitert; ich bin gespannt, ob litestack dafür noch nötig ist und was seine Unterschiede sind.