Kürzlich hatte ich die Gelegenheit, das Hanami-Framework auszuprobieren, indem ich einen der Microservices für unseren Kunden erstellte.

Ich war begeistert. Ich verfolge die Entwicklung von Hanami schon seit einiger Zeit und konnte es nicht mehr erwarten, es in einem echten Projekt auszuprobieren.

Es war sehr nett, dass unser Kunde, Yousty AG, im Geiste der Innovation, in ein völlig (für unser Team) neues Ruby-Framework investiert hat.

So gings.

Der Umfang

Ich wollte einen Favoriten-Service entwickeln.

In Yousty setzen wir auf die Microservice-Architektur, und das Favorisieren ("zur Merkliste hinzufügen") war die nächste Funktion, die wir aus unserem grossen Monolithen herausholen wollten.

Yousty ist ein grossartiges Unternehmen, das Entwickler:innen ermutigt, neue Dinge und Lösungen mit verschiedenen Technologien auszuprobieren. Dabei ist es wichtig, das Geschäftsrisiko zu managen, während man das alles tut.

Der Versuch, einen völlig neuen Rahmen zu schaffen, ist nicht keine kleine Sache, die man einfach tun kann. Also mussten wir dieses Thema vorsichtig angehen.

Aber WARUM überhaupt das Risiko eingehen?

Die Erklärung, warum man sich nicht für Rails als Anwendungsframework entschieden hat ist einen eigenen Artikel wert. Ich werde nicht ins Detail gehen, aber einige der Gründe, die gegen den Einsatz von Rails sprechen, wurden bereits behandelt, so dass ich empfehle, dort nachzusehen.

Wir haben mehr und mehr Probleme mit Rails erlebt, je mehr wir unser Geschäft vergrössert haben und je kompliziertere Probleme wir zu lösen hatten. Aber wir halten auch nicht an einer bestimmten Technologie fest, nur weil wir sie kennen. Es ist eine sehr gefährliche Sache, sich mit der bekannten Architektur, dem Technologie-Stack oder den Prozessen zu sehr anzufreunden - wir könnten leicht die grossen Chancen verpassen, uns weiterzuentwickeln und an der Spitze der Konkurrenz zu bleiben.

Innovation ist ein wichtiger Aspekt der Technologie und ich gehöre zu den Menschen, die andere wirklich ermutigen, neue Dinge auszuprobieren.

Der Service

Der Favoriten Service, mit nur 4 API-Endpunkten, war der perfekte Kandidat für eine Innovation. Es ist so klein, dass es im Falle eines Fehlers ca. einen Tag dauern würde, es in Rails umzuschreiben, und es ist keine Schlüsselfunktion für unseren Kunden.

So war das Risiko wirklich gering, und wir haben grünes Licht bekommen, Hanami 2.0 zu testen.

Meine anfänglichen Fehler

Zunächst einmal möchte ich einen der beiden grössten Fehler, die ich bei der Implementierung des Dienstes in Hanami gemacht habe, erläutern.

1. Hanami sah verlassen aus.

Ich wusste, dass Hanami zu der Zeit in einem Prozess des kompletten Refactorings war, und es wurde intensiv daran gearbeitet, die Version 2.0 zu vollenden. Aber ich musste sicherstellen, dass das Projekt aktiv ist, sodass die Leute sich engagieren können und die Entwicklung wirklich intensiv bleibt.

Ich bin die GitHub-Einsichten durchgegangen und dann wartete eine erste grosse Überraschung auf mich.

Es gab fast KEIN einziges Update im Hanami-Hauptrepository in den letzten 6 Monaten! Das sah nicht vielversprechend aus. Ich habe versucht, die Aktivität des master-Branches zu überprüfen, und habe festgestellt, dass er auf Version 1.3 verweist, aber ich konnte nicht einmal den Hanami 2.0 Branch finden...

Dies war ein Problem, das aber kürzlich durch eine Repository-Bereinigung behoben wurde - nun speichert der Standard-Branch main tatsächlich den neuesten Code.

So habe ich mich an das Kernteam gewandt und gefragt, wo die Arbeit bleibt und sie haben mich beruhigt. Piotr Solnica erklärt es auch in einem seiner letzten Hanami-Vorträge.

Mono-Repo vs. mehrere Repositories

Zunächst einmal, Hanami ist in unabhängige Komponenten aufgeteilt, und das Haupt-Repository klebt sie einfach alle zusammen - es ist also nicht nötig, zu viel Arbeit in das Haupt-Repository zu stecken, sondern eher in jede einzelne Komponente.

Dies ist ein grundlegender Unterschied zu bspw. Rails, wo es ein grosses Mono-Repo gibt - das die Aktivität von allen Komponenten zusammenfasst!

Es war also sehr wichtig zu erkennen, dass wir, um die tatsächliche Aktivität im Rahmen von Hanami zu überprüfen, das Gesamtbild betrachten und in verschiedene Repositories schauen mussten.

ROM + DRY + Hanami

Die andere sehr wichtige Information, die hervorzuheben ist, ist, dass Hanami 2.0 durch die Kombination von drei grossen Edelsteinfamilien aufgebaut ist.

• DRY-RB gems - eine Sammlung unabhängiger Bibliotheken, von denen jede eine einzelne Aufgabe erfüllt und die zusammen ein mächtiges Toolset für Ruby-Anwendungen darstellen.

• ROM-RB - ist ein extrem leistungsfähiges und flexibles Persistenz-Framework, das die Anbindung an jede Art von Datenspeicher ermöglicht.

• Hanami components - alle Hanami-Komponenten, die für die einfache Erstellung kompletter, skalierbarer Ruby-Anwendungen entwickelt wurden.

Es hat sich herausgestellt, dass um Hanami 2.0 möglich zu machen, mussten die Autoren die Kräfte all dieser drei Gem-Familien bündeln und eine Menge Arbeit in jede von ihnen stecken, um alle Gems, die Hanami in der nächsten Hauptversion verwenden würde, anzupassen, zu stabilisieren und zu verbessern.

Als ich das realisiert habe, war ich endlich zufrieden. Die Leute arbeiteten an Hanami. Tatsächlich arbeiten sie wie verrückt und es war ein relativ geringes Risiko, dass sie dieses Projekt aufgegeben würden.

2. Die irreführende Hanami-API

Ich habe einen Blogbeitrag im offiziellen Hanami-Blog gesehen, veröffentlicht von Tim Riley, über die Einführung von Hanami::API.

Er veröffentlichte einige verrückte Benchmark-Ergebnisse, die zeigen, wie performant Hanami::API im Vergleich zu rails ist:

Für vollständige Benchmarks empfehle ich dringend den Originalbeitrag zu lesen.

Alles war gut, ausser dass ich aus einer Rails-Welt komme. Ich habe Rails::API jahrelang verwendet! Und als ich den Namen Hanami::APi gesehen habe, bin ich sofort davon ausgegangen, dass es sich um eine komplette Hanami APP handelt, aber ohne Views...

Was eine völlig falsche Annahme war, die unnötige Verzögerungen verursacht hat.

Ich habe ein Projekt mit Hanami::API begonnen, und habe schnell gemerkt, dass es weit davon entfernt ist, ein "komplettes" Anwendungsframework zu sein. Die Menge der benötigten Konfigurationen war einfach verrückt, und der Mangel an Ressourcen, die im Web verfügbar waren, war eine ziemliche Herausforderung.

Nach einer Weile, wandte ich mich wieder an das Hanami Kernteam, und sie erklärten mir meinen Fehler.

Hanami API ist nicht dafür gedacht, als komplettes Web-Framework verwendet zu werden.

Es scheint, dass in Hanami jede beliebige Komponente ein- und ausgeschaltet werden kann! Es gibt keine feste Abhängigkeit von Views oder einer bestimmten Persistenz-Engine, so dass es nicht notwendig ist, ein Unterprojekt speziell für API-Bedürfnisse zu erstellen.

In der Tat ist Hanami so flexibel, dass Sie es an alles anpassen können.

Brauchen Sie überhaupt eine Datenbank? Deaktivieren Sie sie - oder entfernen Sie sie ganz.

Brauchen Sie ein WEB-Interface, einen Router, überhaupt? Deaktivieren Sie es - oder entfernen Sie es ganz.

Der Hanami::API war nur ein winziger Webpart, aus dem ein Router extrahiert wurde, so dass wir ihn in sehr kleinen Anwendungen verwenden können, ähnlich wie Sinatra.

Nachdem ich diese Informationen erhalten hatte, musste ich nur ein paar Mal mit dem Kopf auf meinen Schreibtisch schlagen...

...und dann wieder starten - diesmal richtig.

Schreiben einer Hanami 2.0-Dienstanwendung

Das Schreiben der kompletten Anwendung von Grund auf war einfacher als ich erwartet hatte. Ich musste durch ROM-rb guides durchgehen, und das war manchmal frustrierend, da ich als erfahrener Ruby-Entwickler die Syntax für eine find-Methode überprüfen musste, oder wie man Tests für den Router schreibt.... aber das waren nur kleine Verlangsamungen.

Vielleicht lag es daran, wie wir bereits mit unseren Rails-Diensten gearbeitet haben, indem wir den Grossteil unserer Geschäftslogik in den Ordner lib legten. Oder vielleicht, weil keine Angst vor zusätzlichen Abstraktionen vorhanden war und unsere Rails-Modelle mit nur Persistenzinformationen leer bleiben konnten... Was auch immer es war, es war wirklich einfach für mich, die App in Hanami zu schreiben, und alles funktionierte sofort.

Es war einfach, es funktionierte, ich war in der Lage, die komplette Anwendung zu erstellen, noch bevor die erste alpha Version von Hanami 2.0 veröffentlicht worden war.

Das war super vielversprechend.

Die finale Entscheidung

Dann hatten wir einen Anruf in unserem Team und wir haben beschlossen, diese Anwendung auf Rails umzuschreiben.

Sind Sie überrascht? Lassen Sie mich das erklären.

Um eine endgültige Entscheidung zu treffen, musste ich ein paar Faktoren berücksichtigen.

1. Einfachheit, dem Team ein neues Framework beizubringen, ohne es zu verlangsamen.

Da sich Hanami 2.0 noch in einem sehr frühen Stadium befand, gab es noch keine grosse Community, die hinter dem Projekt stand, und daher gab es nicht genügend Ressourcen zur Verfügung, um unserem Team das neue Framework einfach beizubringen, ohne es zu sehr zu verlangsamen.

Ich bin dieses Problem sofort angegangen, indem ich das Hanami-Mastery-Projekt gestartet habe, das Videoanleitungen, Artikel, und Tutorials anbot, um neuen Entwickler:innen zu helfen, Hanami so schnell und mühelos wie möglich zu meistern.

Aber ich bin ein Innovator und Frühanwender jeder vielversprechenden Technologie, die mir begegnet - ich würde jedoch nie jemanden dazu zwingen, das Gleiche zu tun. Ich kann helfen, Dinge einfacher zu machen, ich kann helfen, eine Gemeinschaft aufzubauen, ich kann führen - aber ich zwinge mein Team nicht, den Weg für andere zu ebnen.

2. Der Aufwand für die Infrastruktur.

Auch hier gab es aufgrund des frühen Stadiums, einige Dinge, die ich von Grund auf neu schreiben musste - und wir haben sie bereits in unseren Rails-Anwendungen gelöst. Dinge wie App-Scaffold-Generatoren, die Deployment-Skripte, etc.

Das Hauptproblem war, dass wir, als wir unsere Lösungen geschrieben haben, nicht allzu viel darüber nachgedacht haben, dass unsere Komponenten Rails-unabhängig sein sollten, und es wäre auch nicht immer einfach, dies im Auge zu behalten.

Auf jeden Fall war es eine zusätzliche Verlangsamung, und je kompliziertere Projekte wir machen würden, desto mehr solches Zeug würden wir umschreiben müssen.

3. Die Grösse des Hanami-Teams und die Entwicklungsgeschwindigkeit.

Der dritte Faktor, den ich für meinen Kunden als etwas riskant empfunden habe, war die Grösse des Kernteams und die Fristen, zu deren Einhaltung sie sich verpflichtet haben.

Hanami 2.0 war bereits ein Jahr nach der angestrebten Veröffentlichung im Verzug, und es dauerte wahrscheinlich noch ein Jahr, bis die offizielle, stabile Version auf den Markt kommen würde.

Auch war es MEIN Problem, dass ich ein "Ziel" als eine Art "Versprechen" gesehen habe, was die falschen Annahmen verursachte.

Auf der anderen Seite arbeiten die Leute, die an Open-Source-Projekten arbeiten, in ihrer Freizeit, ohne für ihre grossartige Arbeit bezahlt zu werden, bis das Projekt wirklich populär wird und ein sinnvolles Sponsoring erhält. Sie arbeiten nachts und an Wochenenden, um UNSER Leben einfacher zu machen.

Das ist eine heldenhafte Arbeit, die ich nie genug schätzen kann. Dennoch gibt es eine Menge Erwartungen, wenn es um Open-Source-Projekte geht, aber nicht so viel Bereitschaft, die Arbeit von Menschen finanziell zu unterstützen, um die Dinge zu beschleunigen.

Das ist ein weiterer Grund, warum ich die Hanami Mastery Initiative ins Leben gerufen habe - um andere für eine bessere Unterstützung von grossartigen Open-Source-Projekten zu inspirieren. Sie können mehr über lesen, wie ich die Open-Source-Finanzierung sehe und wie ich beschlossen habe, mich in diesem Bereich zu verbessern.

Aber unabhängig davon, was ich persönlich denke, ist es meine Aufgabe, das Risiko meiner Kunden zu minimieren und gleichzeitig die Wirkung bestimmter Maßnahmen zu maximieren.

Deshalb habe ich auf ein großes Problem hingewiesen, und obwohl ich mich entschlossen habe, diesen Bereich zu verbessern, habe ich auch empfohlen, mit einem Wechsel zu warten.

Zusammenfassung

Manchmal ist es 'schwer zu entscheiden, ob man die gegebene Technologie benutzen soll oder nicht. Die Fähigkeit, den "Hype" zu umgehen, Emotionen beiseite zu schieben und einfach nur Entscheidungen zu kalkulieren und dabei die Interessen der Kundschaft im Auge zu behalten, ist eine extrem wichtige Fähigkeit, und das wünsche ich Ihnen allen. Ich hatte das Glück mit einem grossartigen Team zusammenzuarbeiten, das mir bei schwierigen Entscheidungen hilft.

Hanami ist eine grossartige Wahl, und meiner persönlichen Meinung nach, ist es ein Framework der Wahl für die nahe Zukunft, aber es braucht noch etwas Zeit um die 2.0 Version zu stabilisieren. Ausserdem braucht es Zeit für den Aufbau der Bibliothek von Lernressourcen rund um das Projekt, bei dem ich Stolz mithelfe.

Ich hoffe, dass wir es 2022 noch einmal versuchen können, denn Hanami löst standardmässig die meisten Probleme, die wir mit Rails hatten. Und bis es soweit ist, werde ich hart an der Hanami-Mastery-Initiative arbeiten, um alle Probleme zu lösen, die wir während dieser Erfahrung hatten!