Warum wir Next.js den Rücken kehrten und Ruby on Rails mit Inertia.js lieben gelernt haben

Rechtliche Nachrichten

Die Welt der Webentwicklung verändert sich ständig. Neue Frameworks und Technologien kommen und gehen, doch nur wenige schaffen es, sich nachhaltig zu etablieren und die Herzen von Entwicklerinnen und Entwicklern zu gewinnen. In den letzten Jahren war Next.js eines der beliebtesten Frameworks für React-basierte Webanwendungen. Es versprach eine nahtlose Verbindung von serverseitigem Rendering (SSR), schneller Performance und einfacher Entwicklung.

Doch nach intensiver Nutzung und jahrelangem Einsatz erlebten wir bei Hardcover eine ernüchternde Erkenntnis: Next.js hielt nicht alle Versprechen. Stattdessen fiel unser Blick zurück zu Ruby on Rails – in Kombination mit Inertia.js – und wir entdeckten eine Lösung, die unseren Bedürfnissen oft besser gerecht wird. Die Anfänge und Herausforderungen mit Next.

js Für unser Projekt Hardcover begann die technische Reise mit Next.js, da es zur damaligen Zeit als einer der Vorreiter für React mit serverseitigem Rendering galt. Der Vorteil war gleich offensichtlich: SEO-optimierte Seiten, dynamische Inhalte und die Nutzung moderner JavaScript-Funktionalitäten, die React bietet. Die Einführung von Incremental Static Regeneration durch Next.js Version 9.

5 war ein echter Gamechanger. Sie erlaubte es, Seiten statisch zu generieren, diese aber bei Bedarf zu aktualisieren, um beste Performance und gleichzeitig Aktualität sicherzustellen. Doch die anfänglichen Hoffnungen wurden schnell durch diverse Hindernisse getrübt. Die Architektur mit Next.js und React führte schnell zu komplexen Caching-Problemen, vor allem bei der serverseitigen Verarbeitung von GraphQL-Daten.

Da GraphQL-POST-Requests nicht von Next.js gecacht wurden, mussten wir auf manuelle Caching-Strategien zurückgreifen, die den Entwicklungsaufwand erhöhten und teilweise ineffizient waren. Parallel dazu stiegen unsere Betriebskosten durch die serverlose Architektur drastisch an. Die Hosting-Ausgaben explodierten innerhalb weniger Monate – ein dynamisches Wachstum des Nutzerstamms kann schnell zur Kostenfalle werden, zumal Serverless-Plattformen nach Verbrauch abrechnen. Auch die Entwicklungserfahrung verschlechterte sich: Die Kompilierungszeiten von Next.

js explodierten und lokale Builds dauerten teils mehrere Minuten. Dies hemmte vor allem neue Teammitglieder und bremste den Entwicklungsfluss erheblich. Der Versuch, mit alternativen Tools wie Redis-Caching oder Cloud-Umzügen zu Google Cloud Run Abhilfe zu schaffen, brachte bestenfalls kurzfristige Verbesserungen. Die zugrundeliegende Komplexität und die limitierte Transparenz der Caching-Mechanismen erwiesen sich als schwer überwindbar. Auch das Next.

js-App-Router-Feature und React Server Components konnten die grundlegenden Probleme nicht zufriedenstellend lösen. Der Wunsch nach einer schlankeren, effizienteren Architektur wuchs. Wir suchten nach einem Weg, der uns mehr Kontrolle und Stabilität bietet, vor allem mit Blick auf SEO, Performance und Kosten. Der Blick zurück: Ruby on Rails und die Entdeckung von Inertia.js Ruby on Rails ist kein neues Framework, aber es hat sich gerade in der Kombination mit modernen Frontends seinen festen Platz bewahrt.

Rails hat bewährte Mechanismen für Server Side Rendering, Mature Caching-Lösungen, robuste Datenbankanbindungen und eine klare Architektur, die Entwicklerteams häufig produktiv und stabil arbeiten lässt. Beim Wechsel weg von Next.js stand für uns die Anfrage im Raum, wie moderne Frontend-Technologien wie React weiter integriert werden können. Hier stießen wir auf Inertia.js.

Dieses Framework ist ein Remix zwischen klassischen Serveranwendungen und Single-Page-Applications (SPAs), das es ermöglicht, die Steuerung überwiegend auf dem Server zu belassen – bei gleichzeitiger Nutzung von React-Komponenten für die Benutzeroberfläche. Inertia.js sieht sich nicht als API, sondern als Brücke, die den Server für das Rendern verantwortlich macht, während das Frontend reaktiv bleibt. Dadurch entfällt die Notwendigkeit, eine vollständige REST- oder GraphQL-API für die UI zu implementieren, was Entwicklungszeit spart und Komplexität reduziert. Die Kombination von Ruby on Rails mit Inertia.

js ermöglicht es uns, die bewährten Stärken von Rails wie Caching, Datenbankzugriff (über ActiveRecord) und serverseitiges Rendering direkt auszunutzen, während wir die Flexibilität und Interaktivität von React erhalten. Eine wichtige Erkenntnis war, dass wir auf clientseitige Datenanfragen in vielen Fällen verzichten können, indem wir serverseitig bereits alles relevante zusammenstellen und als Props an React-Komponenten übergeben. Technische Tiefe: So funktioniert unsere neue Architektur Im Kern besteht die neue Architektur darin, dass Anfragen auf dem Server mittels Rails-Controller beantwortet werden. Für jede Route haben wir einen entsprechenden Rails-Controller, der mit Inertia.js das passende React-Template mitsamt den initialen Daten rendert.

Das heißt, Rails hält die volle Kontrolle über die Daten, die an die UI gehen, und nutzt den Rails-Caching-Mechanismus, um häufig genutzte Inhalte wie Homepage-Daten oder trending Bücher effizient zwischenzuspeichern und so die Antwortzeiten erheblich zu beschleunigen. Ein großer Vorteil dieser Herangehensweise liegt in der Reduktion der Komplexität. Anstatt komplexe GraphQL-POST-Anfragen auf dem Client zu verwalten, können wir die Logik serverseitig abarbeiten. Das verringert Fehlerquellen und vereinfacht Sicherheitsüberlegungen, da Authentication und Autorisierung zentral im Rails-Backend liegen. Gleichzeitig lässt sich React auf reine Darstellung konzentrieren, was das Entwicklererlebnis verbessert.

Für das Frontend haben wir mit Vite eine moderne Build-Lösung implementiert, die eine schnelle Entwicklung mit Hot Module Replacement (HMR) und simultaner TypeScript-Unterstützung erlaubt. Die Einbindung von React erfolgt nahtlos in den Rails-Stack. Dabei ersetzen wir den herkömmlichen React Router durch die Rails-Routing-Logik, was ebenfalls den Entwicklungsaufwand senkt, da Routen zentral definiert und genutzt werden. Inertia.js ermöglicht es darüber hinaus, einzelne Teile der Seite, etwa Nutzerinformationen oder Statusanzeigen, nachzuladen und zu aktualisieren, ohne die gesamte Seite neu zu laden – ähnlich wie in klassischen SPAs, aber wesentlich einfacher abzubilden und zu warten.

Performance: Deutliche Vorteile gegenüber Next.js Nachdem wir die Migration abgeschlossen hatten, konnten wir deutliche Verbesserungen in Ladezeiten und Nutzererfahrung beobachten. Google PageSpeed Insights zeigte erhebliche Fortschritte bei der Total Blocking Time, die sich massiv reduzierte. Seiten laden schneller, reagieren besser und fühlen sich für Nutzer insgesamt flüssiger an. Die Fähigkeit, mehrere Cache-Layer (Solid Cache auf Postgres-Basis, Rails-Caching und CloudFlare-basiertes CDN) einzusetzen, sorgt dafür, dass wiederholte Anfragen sehr schnell abgewickelt werden.

Gerade für SEO zählt eine optimierte Seitenladezeit enorm, und das hat sich sofort positiv ausgewirkt. Unerwartete Nebeneffekte der Migration waren auch geringere Hostingkosten. Die Ausgaben für Server in DigitalOcean und das kamal-basierte Deployment blieben stabil und deutlich unter den vorherigen Kosten mit Vercel und Cloud Run. Die stabile Server-Architektur sorgt für besser planbare Kosten und Performance. Auch das Entwicklerteam profitierte vom Wechsel.

Entwicklungszyklen verkürzten sich signifikant, lokale Server starten schneller, und neue Kolleginnen und Kollegen können schneller produktiv sein. Das führt langfristig zu höherer Produktivität und Zufriedenheit im Team. Herausforderungen und Lernkurven Natürlich verlief die Migration nicht ohne Schwierigkeiten. Insbesondere das Debuggen von React-SSR-Problemen stellte sich als herausfordernd heraus, weil die Struktur bei Inertia mit Vite im Zusammenspiel mit Rails neuartig und noch nicht flächendeckend dokumentiert ist. Einige Features, wie das Teilen von Layouts zwischen Seiten, erfordern noch manuelle Lösungen oder Workarounds.

Zudem war die initiale Umstellung von einem auf das andere Paradigma mit komplett serverseitig gesteuerten Datenflüssen für das Frontend ein Umdenken. Während Next.js mit React und seinen Routing- und Komponentensystemen vertraut ist und viele Aufgaben dem Client überlässt, verlangt Inertia.js konsequenteres Server-Denken. Das ist zunächst ungewohnt, bringt aber langfristig Konsistenz.

Die Dokumentation von Inertia.js in Verbindung mit Ruby on Rails ist derzeit noch lückenhaft, was den Einstieg für Entwickler erschwert. Hier hilft die aktive Community und der Austausch auf Plattformen wie Discord, aber es bleibt Luft für bessere Tutorials und Lösungen. Auch wenn wir viele Vorteile von Inertia.js nutzen, bleiben manche Features wie Formularbehandlung oder Datei-Uploads bislang unterrepräsentiert im Einsatz.

Dies ist aber eher eine Folge unserer spezifischen Architektur und des parallelen Einsatzes von Hasura für GraphQL-Anfragen. Eine Zukunftsvision mit weiteren Optimierungen Die Migration war in vielerlei Hinsicht ein Neuanfang und zugleich ein evolutiver Schritt zurück zur Stabilität und Geschwindigkeit. Künftige Verbesserungen sollen den Umgang mit geteilten Layouts vereinfachen und das Potential von InertiaRails.optional besser nutzen, um das Nutzererlebnis noch feingranularer zu steuern – ähnlich wie Streaming-Renderings, jedoch auf einer JS-verwalteten Ebene. Zudem planen wir eine Vertiefung der Verbindung zwischen React und Rails-Backend, um etwa Nutzerinteraktionen noch zielgerichteter und performanter abbilden zu können.

Die Erweiterung der Test-Infrastruktur für SSR-Komponenten und eine engere Integration mit modernen Deployment-Strategien sollen ein weiteres Feld für Effizienzgewinne darstellen. Unsere DevOps-Prozesse haben wir bereits mit Kamal und schlanker Docker-Konfiguration optimiert, die den Vite-Prozess und Rails-Server parallel orchestrieren. Das schafft eine solide Basis für Skalierbarkeit und Ausfallsicherheit. Fazit: Ein Blick auf den Wandel in der Webentwicklung Der Wechsel von Next.js zu Ruby on Rails mit Inertia.

js ist keine Entscheidung gegen moderne JavaScript-Frameworks, sondern vielmehr eine Abwägung von Stärken, Schwächen und Teambedürfnissen. Rails in Kombination mit Inertia.js bietet uns die Kontrolle, Performance und Stabilität, die wir für Hardcover brauchen, um weiter zu wachsen und Leser bestmöglich zu erreichen. Die technische Landschaft bleibt dynamisch. Strategien, die heute gut funktionieren, können morgen schon veraltet sein.