Hanami vs. Rails für Microservices: Praxisbericht

Unser Team hat Hanami 2.0 für einen produktiven Microservice evaluiert, implementiert und am Ende trotzdem auf Rails umgestellt. Dieser Artikel dokumentiert den gesamten Prozess: was funktioniert hat, wo die Grenzen lagen und welche technischen Faktoren die Entscheidung bestimmt haben.

Warum überhaupt ein Rails-Alternativ-Framework testen?

In der Microservice-Architektur unseres Kunden Yousty AG (eine Schweizer Lehrstellenplattform) wollten wir den nächsten Service aus dem Monolithen extrahieren: einen Favoriten-Service mit 4 API-Endpunkten.

Die Ausgangslage: Rails 6.1 lief stabil, aber mit zunehmender Anzahl an Microservices fielen uns wiederkehrende Probleme auf:

• Memory-Overhead: Ein minimaler Rails-API-Service benötigte ca. 80-120 MB RAM im Leerlauf. Bei 15+ Services summiert sich das.
• Boot-Zeit: Rails 6.1 brauchte in unserer Konfiguration 4-8 Sekunden zum Starten. Für Container-Orchestrierung mit schnellem Scaling ist das relevant.
• Implizite Abhängigkeiten: ActiveRecord-Callbacks und Concerns machten es schwer, klare Service-Grenzen zu ziehen.

Einige Gründe, wann Rails nicht die beste Wahl ist, wurden bereits an anderer Stelle behandelt. Unser Kernproblem war spezifischer: Wir brauchten ein leichtgewichtiges Framework, das von Haus aus auf Modularität ausgelegt ist.

Warum gerade Hanami?

Hanami versprach genau das: eine explizite, komponentenbasierte Architektur mit minimalem Overhead. Laut den damaligen Benchmarks von Tim Riley erreichte Hanami::API über 60’000 Requests/Sekunde, verglichen mit ca. 2’800 bei Rails (gemessen mit wrk, einfacher JSON-Endpunkt). Der Memory-Footprint einer Hanami-App lag bei 30-50 MB.

Die Yousty AG unterstützte den Test. Der Favoriten-Service war der perfekte Kandidat: klein genug, um ihn bei einem Fehlschlag in einem Tag auf Rails umzuschreiben, und nicht geschäftskritisch.

Zwei Fehler, die mich Zeit gekostet haben

Das GitHub-Repository sah inaktiv aus

Hanami befand sich mitten im Refactoring für Version 2.0. Als ich die GitHub-Insights prüfte, fand ich fast keine Commits im Hauptrepository der letzten 6 Monate. Der master-Branch zeigte noch auf Version 1.3.

Das Problem: Hanami nutzt ein Multi-Repository-Modell. Der Code verteilt sich auf drei Gem-Familien:

• DRY-RB für Validierung, Dependency Injection und Konfiguration
• ROM-RB für die Persistenzschicht (Repositories, Relations, Changesets)
• Hanami-Komponenten für Routing, Actions und den Anwendungsrahmen

Im Gegensatz zu Rails (ein grosses Mono-Repo, das alle Aktivität bündelt) muss man bei Hanami in mehrere Repositories schauen, um die tatsächliche Entwicklungsaktivität zu beurteilen. Nach einer Rückfrage beim Kernteam war klar: die Arbeit lief intensiv, verteilt auf Dutzende Repositories.

Piotr Solnica erklärt die Architektur-Entscheidung in diesem Vortrag:

Hanami::API ist kein vollständiges Framework

Mein zweiter Fehler kam aus der Rails-Welt: Ich kannte Rails::API als vollständige App ohne Views. Also nahm ich an, Hanami::API sei dasselbe für Hanami.

Falsch. Hanami::API ist nur ein minimaler Router, vergleichbar mit Sinatra. Es fehlt Dependency Injection, Persistenz-Integration, Konfigurationsmanagement und alles andere, was eine produktionsreife App braucht.

Die richtige Lösung: Eine vollständige Hanami-App erstellen und die nicht benötigten Komponenten (Views, Assets) einfach weglassen. Hanami ist so modular aufgebaut, dass jede Komponente einzeln aktiviert oder deaktiviert werden kann. Kein spezielles API-Subprojekt nötig.

Diese Erkenntnis kostete mich einen halben Tag. Danach lief die Entwicklung deutlich schneller.

Implementierung: Hanami 2.0 in der Praxis

Das Schreiben der Anwendung von Grund auf war einfacher als erwartet. Einige Punkte, die auffielen:

Was gut funktionierte:

• Die Projektstruktur erzwingt Trennung von Concerns. Business-Logik landet in lib/, nicht in Models.
• ROM-RB bietet feinere Kontrolle über Queries als ActiveRecord. Kein N+1-Problem durch implizites Lazy Loading.
• Dependency Injection via dry-auto_inject macht Unit-Tests deutlich einfacher. Kein Monkey-Patching nötig.
• Die Boot-Zeit lag bei unter 2 Sekunden (verglichen mit 4-8 Sekunden bei unserem Rails-Setup).

Was schwierig war:

• Die ROM-RB-Dokumentation war lückenhaft. Selbst als erfahrener Ruby-Entwickler musste ich die Syntax für einfache Queries im Quellcode nachschlagen.
• Es gab kaum Stack-Overflow-Antworten oder Community-Ressourcen zu Hanami 2.0.
• Einige Patterns (z.B. Pagination, Error Handling) hatten keine etablierten Konventionen.

Am Ende stand eine funktionsfähige Anwendung, noch bevor die erste Alpha-Version von Hanami 2.0 offiziell erschienen war.

Warum wir trotzdem auf Rails gewechselt haben

Dann kam die Team-Besprechung, und wir entschieden: zurück zu Rails.

Drei Faktoren waren ausschlaggebend:

1. Onboarding-Aufwand für das Team

Die fehlende Community und Dokumentation bedeuteten: Jedes Teammitglied hätte denselben Lernprozess durchlaufen müssen, den ich hatte. Bei einem Team von 8 Entwickler:innen ist das ein enormer Zeitverlust.

Ich habe daraufhin das Hanami Mastery-Projekt gestartet, um Tutorials und Guides bereitzustellen. Aber das änderte nichts an der akuten Situation: Unser Team musste jetzt produktiv sein, nicht in 6 Monaten.

2. Fehlende Infrastruktur-Tooling

Unsere bestehenden Scaffold-Generatoren, Deployment-Skripte und CI/CD-Pipelines waren alle auf Rails zugeschnitten. Für Hanami hätten wir diese Tools neu schreiben müssen. Bei einem Service mag das noch machbar sein, aber bei 15+ geplanten Microservices wird der Aufwand unverhältnismässig.

Das Kernproblem: Wir hatten unsere Toolchain nicht framework-agnostisch gebaut. Ein strategischer Fehler, der sich hier zum ersten Mal bemerkbar machte.

3. Release-Unsicherheit bei Hanami 2.0

Hanami 2.0 war zu dem Zeitpunkt bereits ein Jahr über dem ursprünglichen Release-Ziel. Die stabile Version würde voraussichtlich noch ein weiteres Jahr dauern (tatsächlich erschien Hanami 2.0.0 erst im November 2022, die aktuelle stabile Version ist 2.2.x).

Das Kernteam leistete beeindruckende Arbeit, grösstenteils in ihrer Freizeit. Open-Source-Entwicklung folgt aber eigenen Zeitplänen. Für einen Kunden, der Planungssicherheit braucht, war das ein zu hohes Risiko.

USEO’s Einschätzung: Hanami vs. Rails für Microservices (Stand 2025)

Bei USEO arbeiten wir seit über 10 Jahren mit Ruby und Rails. Wir haben Hanami verfolgt, evaluiert und in internen Prototypen getestet. Hier ist unsere ehrliche Einschätzung:

Wir setzen für Kunden-Projekte weiterhin auf Rails, und zwar aus pragmatischen Gründen:

• Ecosystem-Reife: Rails 7.2+ mit Puma hat den Memory-Gap deutlich verkleinert. Ein minimaler Rails-API-Service liegt jetzt bei 50-70 MB RAM (mit RUBY_GC_HEAP_INIT_SLOTS optimiert), verglichen mit 30-50 MB bei Hanami.
• Developer-Pool: Für Kunden, die nach dem Projekt ein Team aufbauen oder wechseln müssen, ist die Verfügbarkeit von Rails-Entwickler:innen ein entscheidender Faktor.
• Produktivität: Rails’ “Convention over Configuration” beschleunigt die Entwicklung bei Standard-Anforderungen enorm. Hanami erfordert mehr explizite Entscheidungen, was bei kleinen Teams zu Overhead führt.

Wo Hanami tatsächlich besser ist:

• Projekte mit komplexen Domänenmodellen, bei denen ActiveRecord’s Vermischung von Persistenz und Business-Logik zum Problem wird
• Teams, die bereits Erfahrung mit DRY-RB und ROM-RB haben
• Event-driven Microservices, bei denen der modulare Aufbau von Hanami (Slices) natürlicher passt als Rails Engines

Unser Fazit: Hanami 2.2 ist ein ausgereiftes Framework. Aber “besser” bedeutet nicht automatisch “die richtige Wahl”. Die richtige Framework-Entscheidung hängt vom Team, vom Projekt-Kontext und von der langfristigen Wartbarkeit ab.

Memory-Footprint und Performance im Vergleich

Für Teams, die eine datenbasierte Entscheidung treffen wollen, hier die ungefähren Werte aus unseren Tests (Ruby 3.3, JSON-API-Endpunkt, gemessen mit derailed_benchmarks und wrk):

Metrik	Rails 7.2 API	Hanami 2.2	Faktor
RAM (idle)	55-70 MB	30-45 MB	~1.5x
Boot-Zeit	2-4 s	0.8-1.5 s	~2x
Req/s (einfacher JSON)	~8’500	~12’000	~1.4x
Req/s (DB-Query)	~3’200	~3’800	~1.2x

Bei DB-lastigen Endpunkten (was die Mehrheit realer APIs ausmacht) schrumpft der Performance-Unterschied deutlich. Die Datenbank ist fast immer der Bottleneck, nicht das Framework.

Was ich daraus gelernt habe

Technologie-Entscheidungen basieren nicht nur auf Benchmarks. Die Fähigkeit, den Hype zu ignorieren und kühl zu kalkulieren, ist eine der wichtigsten Engineering-Kompetenzen. Drei Leitfragen helfen dabei:

1. Kann mein Team das in 3 Monaten ohne mich warten? Wenn nicht, ist die Technologie zu exotisch.
2. Wie gross ist der Blast Radius bei einem Fehlschlag? Ein kleiner Service ist das ideale Experimentierfeld.
3. Löst das neue Tool ein echtes Problem oder nur ein gefühltes? Der Memory-Unterschied zwischen Rails und Hanami rechtfertigt selten allein einen Wechsel.

Hanami bleibt ein starkes Framework und verdient mehr Aufmerksamkeit. Für das richtige Projekt und das richtige Team kann es die bessere Wahl sein. Aber die Entscheidung muss auf Fakten basieren, nicht auf Begeisterung.