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, investiert hat, um dieses (für unser Team) völlig neue Ruby-Framework auszuprobieren.

Hier ist, wie es ging.

Der Umfang

Ich wollte einen Favoriten-Service entwickeln.

In Yousty setzen wir auf die microservice architecture, und das Favorisieren war die nächste Funktion, die wir aus unserem großen Monolithen herausholen wollten.

Yousty ist ein großartiges Unternehmen, das Entwickler ermutigt, neue Dinge, neue Lösungen auszuprobieren, und Tech-Stacks auszuprobieren, aber gleichzeitig ist es wichtig, das Geschäftsrisiko zu managen, während man das tut.

Der Versuch, einen völlig neuen Rahmen zu schaffen, ist nicht die kleinste Sache, die man 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 entscheiden konnte{ 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ößert haben und je kompliziertere Probleme wir'zu lösen haben. 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 Tech-Stack oder den Prozessen zu sehr anzufreunden - wir könnten leicht die großen 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.

The service

The favoriting service, mit nur 4 API-Endpunkten, war der perfekte Kandidat für eine Innovation. Es'ist so klein, dass es im Falle eines Fehlers vielleicht einen Tag oder so dauern würde, es in Rails umzuschreiben, und es'ist keine Schlüsselfunktion für unser Geschäft.

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ößten 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, aber ich musste sicherstellen, dass das Projekt aktiv ist, dass die Leute sich engagieren und die Entwicklung wirklich intensiv ist.

Ich bin die GitHub-Einsichten durchgegangen und dann wartete eine erste große Ü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-Zweiges zu überprüfen, und habe festgestellt, dass er auf Version 1.3 verweist, aber ich konnte nicht einmal den Hanami 2.0 Zweig finden...

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

So ich habe 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 die unabhängigen Komponenten aufgeteilt, und das Haupt-Repository klebt sie einfach alle zusammen - ist es nicht nötig, zu viel Arbeit in das Haupt-Repository zu stecken, sondern eher in jede einzelne Komponente.

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

So Es war wirklich wichtig zu erkennen, dass wir, um die tatsächliche Aktivität innerhalb des Hanami-Rahmens 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 großen 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 für Hanami 2.0 möglich zu machen, mussten die Autoren all dieser drei Edelsteinfamilien ihre Kräfte bündeln und eine Menge Arbeit in jede von ihnen stecken, um alle Edelsteine, 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 dieses Projekt aufgegeben werden würde.

2. Die irreführende Hanami-API

I'habe einen Blogbeitrag im offiziellen Hanami-Blog gesehen, veröffentlicht von Tim Riley, über introducing Hanami::API.

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

Für vollständige Benchmarks empfehle ich dringend reading the original post.

Alles war gut, außer dass Ich'komme aus einer Rails-Welt. I've used Rails::API for years! 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 ich 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, ich wandte 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 keine Datenbank?

Deaktivieren Sie sie - oder entfernen Sie sie ganz.

Brauchen Sie ein WEB-Interface, einen Router, überhaupt nicht?

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 mich durch ROM-rb guides, und das war manchmal frustrierend, dass 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 Großteil unserer Geschäftslogik in den Ordner lib legten, oder vielleicht, weil keine Angst vor zusätzlichen Abstraktionen hat und unsere Rails-Modelle leer bleiben, mit nur Persistenzinformationen... Was auch immer es war, es war wirklich einfach für mich, die App in Hanami zu schreiben, und alles funktionierte sofort nach dem Auspacken.

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.

The final decision

Then we had einen Anruf in unserem Team und wir'haben beschlossen, diese App auf Rails umzuschreiben.

Are you surprised? Lassen Sie mich erklären.

Um eine endgültige Entscheidung zu treffen, musste ich einige 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 große Community, die hinter dem Projekt stand, und daher standen nicht genügend Ressourcen zur Verfügung, um unserem Team das neue Framework einfach beizubringen, ohne es zu sehr zu verlangsamen.

Ich habe dieses Problem sofort angegangen, indem ich die Hanami Mastery Projekt, das Videoanleitungen, Artikel, und Tutorials , um neuen Entwicklern zu helfen, Hanami so schnell und mühelos wie möglich zu meistern.

Aber ich bin ein Innovator und Early Adopter jeder vielversprechenden Technologie, die mir begegnet - wie auch immer, Ich'würde nie jemanden 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 Infrastruktur-Overhead.

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öße des Hanami-Teams und die Entwicklungsgeschwindigkeit.

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

Hanami 2.0 war bereits ein Jahr nach der angestrebten Veröffentlichung, 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, bis das Projekt wirklich populär wird und bedeutendes Sponsoring bekommt, arbeiten die Leute, die an Open Source Projekten arbeiten, in ihrer Freizeit, ohne für die großartige Arbeit, die sie machen, bezahlt zu werden! Sie arbeiten nachts und an Wochenenden, um UNSER Leben einfacher zu machen.

Das'ist eine heroische 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 großartigen 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 des Kunden im Auge zu behalten, ist eine extrem wichtige Fähigkeit, und das wünsche ich Ihnen allen. Ich hatte das Glück mit einem großartigen Team zusammenzuarbeiten, das helps me making such hard decisions.

Hanami ist eine großartige 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. Außerdem braucht es Zeit für den Aufbau der Bibliothek von Lernressourcen rund um das Projekt , bei dem ich mit Stolz helfe.

Ich hoffe, wir'können es 2022 noch einmal versuchen, denn Und bis das passiert, werde ich ' hart an Hanami-Mastery-Initiative, um alle Probleme zu lösen, mit denen wir während dieser Erfahrung konfrontiert wurden!