Ostatnio miałem okazję wypróbować framework Hanami budując jeden z mikroserwisów dla naszego klienta.

Byłem podekscytowany. Obserwowałem rozwój Hanami już od dłuższego czasu i nie mogłem się już doczekać, żeby wypróbować go w prawdziwym projekcie.

To było niezmiernie miłe ze strony naszego klienta, Yousty AG, że w duchu innowacji, zainwestował w wypróbowanie tego zupełnie nowego (dla naszego zespołu) ruby frameworka.

Oto jak to przebiegło.

Zakres

Miałem stworzyć serwis dodawania do ulubionych.

W Yousty przyjęliśmy architekturę mikroserwisów, a dodawanie do ulubionych było kolejną funkcją, którą chcieliśmy wyodrębnić z naszego dużego monolitu.

Yousty to świetna firma, zachęcająca programistów do wypróbowywania nowych rzeczy, nowych rozwiązań i stosów technologicznych, ale jednocześnie ważne jest zarządzanie ryzykiem biznesowym podczas robienia tego.

Wypróbowanie zupełnie nowego frameworka to nie najmniejsza rzecz do zrobienia, więc musieliśmy podejść do tego tematu ostrożnie.

Ale DLACZEGO w ogóle podejmować ryzyko?

Wyjaśnienie dlaczego można nie wybrać Rails jako framework aplikacji jest warte osobnego artykułu. Nie będę wchodzić w szczegóły, ale niektóre powody, żeby nie używać Rails zostały już omówione, więc polecam sprawdzenie tego.

Doświadczaliśmy coraz więcej problemów z Rails im bardziej skalowaliśmy nasz biznes i im bardziej skomplikowane problemy mieliśmy do rozwiązania. Ale także jesteśmy w mentalności niełpienia się przy konkretnej technologii TYLKO dlatego, że ją znamy. To bardzo niebezpieczna rzecz, zbyt wygodne stanie się ze znaną architekturą, stosem technologicznym czy procesami - łatwo możemy przegapić wspaniałe okazje do ewolucji i pozostania na szczycie konkurencji.

Innowacja jest ważnym aspektem technologii i jestem jedną z osób, które naprawdę zachęcają innych do wypróbowywania nowych rzeczy.

Serwis

Serwis dodawania do ulubionych z tylko 4 endpointami API był idealnym kandydatem do innowacji. Jest tak mały, że w przypadku niepowodzenia przepisanie go do Rails zajęłoby może dzień i nie jest to kluczowa funkcja dla naszego biznesu.

Więc ryzyko było naprawdę małe i dostaliśmy zielone światło do wypróbowania Hanami 2.0.

Moje początkowe błędy

Po pierwsze, przejdźmy przez jeden z dwóch największych błędów, które popełniłem podczas implementacji serwisu w Hanami.

1. Hanami wyglądał na porzucony.

Wiedziałem, że Hanami był w procesie kompletnego refaktoringu w tym czasie i trwały intensywne prace nad ukończeniem wersji 2.0, ale musiałem upewnić się, że projekt jest aktywny, że ludzie są zaangażowani i rozwój jest naprawdę intensywny.

Przejrzałem wtedy GitHub insights i czekała na mnie pierwsza duża niespodzianka.

Przez ostatnie 6 miesięcy prawie NIE BYŁO żadnych aktualizacji w głównym repozytorium Hanami! To nie wyglądało obiecująco. Spróbowałem sprawdzić aktywność brancha master i zdałem sobie sprawę, że wskazuje na wersję 1.3, ale nie mogłem nawet znaleźć brancha Hanami 2.0...

To był problem, ale został niedawno naprawiony przez uporządkowanie repozytorium - teraz domyślny branch main rzeczywiście przechowuje najnowszy kod.

Więc skontaktowałem się z głównym zespołem, pytając gdzie odbywa się praca i uspokoili mnie. Piotr Solnica wyjaśnia to też w jednym ze swoich ostatnich wystąpień o Hanami

Mono-Repo vs wiele repozytoriów

Po pierwsze, Hanami jest podzielone na niezależne komponenty, a główne repozytorium po prostu skleja je wszystkie razem - nie ma potrzeby zbyt dużej pracy w głównym repozytorium, ale raczej w każdym z komponentów.

To fundamentalna różnica w stosunku do na przykład Rails, gdzie jest duże mono-repo - które sumuje aktywność ze wszystkich komponentów razem!

Więc naprawdę ważne było zrozumienie, że żeby sprawdzić prawdziwą aktywność w frameworku Hanami, musieliśmy zobaczyć szerszy obraz i spojrzeć na różne repozytoria.

ROM + DRY + Hanami

Druga bardzo ważna informacja do podkreślenia była taka, że Hanami 2.0 jest zbudowane przez połączenie trzech dużych rodzin gemów.

• DRY-RB gemy - kolekcja niezależnych bibliotek, z których każda wykonuje pojedyncze zadanie, a razem stanowią potężny zestaw narzędzi dla aplikacji ruby.

• ROM-RB - niezwykle potężny i elastyczny framework perzystencji, pozwalający na połączenie z dowolnym rodzajem magazynu danych.

• Komponenty Hanami - wszystkie komponenty hanami, zbudowane do łatwego tworzenia kompletnych, skalowalnych aplikacji ruby.

Okazuje się, że żeby umożliwić Hanami 2.0, autorzy wszystkich trzech rodzin gemów musieli połączyć siły i włożyć ogromną pracę w każdy z nich żeby dostosować, ustabilizować i ulepszyć wszystkie gemy, których Hanami użyłoby w następnym głównym wydaniu.

Kiedy to zrozumiałem, w końcu zostałem usatysfak‌cjonowany. Ludzie PRACOWALI nad Hanami. Właściwie pracują jak szaleni i było relatywnie małe ryzyko, że ten projekt zostanie porzucony.

2. Mylące Hanami-API

Widziałem post na blogu w oficjalnym blogu Hanami, opublikowany przez Tim Riley, o wprowadzeniu Hanami::API.

Opublikował szalone wyniki benchmarków, pokazując jak wydajne jest Hanami::API w porównaniu do rails

Dla pełnych benchmarków, gorąco polecam przeczytanie oryginalnego postu.

Wszystko było w porządku, z wyjątkiem tego, że przychodziłem ze świata Rails. Używałem Rails::API przez lata! A kiedy zobaczyłem nazwę Hanami::API, natychmiast założyłem, że to kompletna aplikacja Hanami, ale bez widoków...

Co było kompletnie błędnym założeniem, które spowodowało niepotrzebne opóźnienie.

Zacząłem projekt używając Hanami::API i szybko zdałem sobie sprawę, że to bardzo daleko od nazywania tego "kompletnym" frameworkiem aplikacji. Ilość wymaganej konfiguracji była po prostu szalona, a brak dostępnych zasobów w sieci był dość wyzwaniem.

Po chwili znowu skontaktowałem się z głównym zespołem Hanami i wyjaśnili mój błąd.

Hanami API nie jest przeznaczone do użycia jako kompletny framework webowy.

Okazuje się, że w Hanami możesz włączać i wyłączać każdy komponent, jaki chcesz! Nie ma twardej zależności od widoków czy danego silnika perzystencji, więc nie ma potrzeby tworzenia podprojektu specyficznego dla potrzeb API.

W rzeczywistości Hanami jest tak elastyczne, że możesz dostosować je do pracy z czymkolwiek.

Nie potrzebujesz w ogóle bazy danych?

Wyłącz ją - lub usuń całkowicie.

Nie potrzebujesz interfejsu WEB, routera, w ogóle?

Wyłącz go - lub usuń całkowicie.

Hanami::API był po prostu małą częścią webową z wyodrębnionym routerem, więc możemy go używać w bardzo małych aplikacjach, podobnie jak Sinatra.

Po otrzymaniu tej informacji musiałem tylko uderzyć głową o biurko kilka razy...

...a potem zacząć od nowa - tym razem poprawnie.

Pisanie aplikacji serwisowej Hanami 2.0

Napisanie kompletnej aplikacji od zera było łatwiejsze niż oczekiwałem. Musiałem przejść przez przewodniki ROM-rb i czasami było frustrujące, że jako senior Ruby developer musiałem sprawdzić składnię dla metody find lub jak pisać testy dla routera... ale to były drobne spowolnienia.

Może dlatego, jak już pracowaliśmy z naszymi serwisami Rails, umieszczając większość naszej logiki biznesowej w folderze lib, lub może dlatego, że nie baliśmy się dodatkowych abstrakcji i utrzymywaliśmy nasze modele Rails puste, z tylko informacjami o perzystencji... Cokolwiek to było, naprawdę łatwo było mi napisać aplikację w Hanami i wszystko działało od razu.

Było łatwo, działało, mogłem złożyć kompletną aplikację jeszcze przed wydaniem pierwszej wersji alpha Hanami 2.0.

To było super obiecujące.

Ostateczna decyzja

Potem mieliśmy rozmowę w naszym zespole i zdecydowaliśmy przepisać tę aplikację do Rails.

Jesteś zaskoczony? Pozwól mi wyjaśnić.

Żeby podjąć ostateczną decyzję musiałem rozważyć kilka czynników.

1. Łatwość nauczenia zespołu nowego frameworka bez spowalniania.

Z powodu bardzo wczesnego etapu Hanami 2.0, nie było jeszcze zbyt dużej społeczności zbudowanej wokół projektu, a więc nie było wystarczająco dużo dostępnych zasobów, żeby łatwo nauczyć nasz zespół nowego frameworka bez zbytniego spowalniania.

Natychmiast zajęłem się tym problemem zaczynając projekt Hanami Mastery, produkując przewodniki wideo, artykuły i tutoriale żeby pomóc nowym programistom opanować Hanami tak szybko i bezwysiłkowo jak to możliwe.

Ale jestem innowatorem i wczesnym adoptyrem każdej obiecującej technologii, na którą natrafię - jednak nigdy nie zmuszałbym nikogo do robienia tego samego. Mogę pomóc ułatwić sprawy, pomóc budować społeczność, mogę przewodzić - ale nie zmuszać mojego zespołu do torowania drogi dla innych.

2. Narzut infrastruktury.

Znowu, z powodu wczesnego etapu, było całkiem sporo rzeczy, które musiałem napisać od zera - a już rozwiązaliśmy je w naszych aplikacjach Rails. Rzeczy jak generatory szkieletu aplikacji, skrypty wdrożeniowe, itp.

Głównym problemem było to, że kiedy pisaliśmy nasze rozwiązania nie myśleliśmy zbyt dużo o tym, żeby nasze komponenty były niezależne od rails, ani nie byłoby to zawsze łatwą rzeczą do pamiętania.

W każdym razie było to dodatkowe spowolnienie, a im bardziej skomplikowane projekty robilibyśmy, tym więcej takich rzeczy musielibyśmy przepisać.

3. Wielkość zespołu Hanami i szybkość rozwoju.

Potem trzeci czynnik, który widziałem jako nieco ryzykowny dla mojego klienta, to wielkość głównego zespołu i terminy, które zobowiązali się spełnić.

Hanami 2.0 był już rok po docelowej dacie wydania i prawdopodobnie był jeszcze rok przed oficjalną, stabilną wersją.

Jako że sam jestem kontrybutorem open-source, szybko zrozumiałem dlaczego tak się stało. To nie jest tak, że wymagam od kogokolwiek w świecie Open Source trzymania się jakichkolwiek terminów.

Także to był MÓJ problem, że widziałem "cel" jako jakąś "obietnicę", co spowodowało błędne założenia.

Z drugiej strony, dopóki projekt nie stanie się naprawdę popularny i nie otrzyma znacznego sponsorowania, ludzie pracujący nad projektami Open Source pracują w swoim wolnym czasie, bez otrzymywania zapłaty za wspaniałą pracę, którą wykonują! Pracują podczas nocy i weekendów, żeby ułatwić NASZE życie.

To heroiczna praca, której nigdy nie mógłbym docenić wystarczająco. Wciąż jest dużo oczekiwań jeśli chodzi o projekty Open-Source, ale nie za dużo chęci finansowego wspierania pracy ludzi żeby przyspieszyć sprawy.

To kolejny powód dlaczego zacząłem inicjatywę Hanami Mastery - żeby zainspirować innych do lepszego wspierania wspaniałych projektów Open Source. Możesz przeczytać więcej o jak widzę finansowanie Open Source i jak zdecydowałem się poprawić w tej dziedzinie.

Jednak niezależnie od tego, co myślę osobiście, moją pracą jest minimalizowanie ryzyka, jakie biorą moi klienci, jednocześnie maksymalizując efekt pewnych działań.

Dlatego wskazałem to jako duży problem, i chociaż zdecydowałem się poprawić w tej dziedzinie, zaleciłem też czekanie przed przejściem.

Podsumowanie

Czasami trudno jest zdecydować, czy użyć danej technologii czy nie. Umiejętność ominięcia "hype'u", odłożenia na bok emocji i po prostu kalkulowania decyzji mając na uwadze interes klienta to niezwykle ważna umiejętność i tego życzę wam wszystkim. Miałem szczęście pracować ze wspaniałym zespołem, który pomaga mi podejmować takie trudne decyzje.

Hanami to wspaniały wybór, i moim osobistym zdaniem to framework wyboru na najbliższą przyszłość, ale potrzebuje jeszcze czasu żeby ustabilizować wersję 2.0. Także potrzebuje czasu na zbudowanie biblioteki zasobów edukacyjnych wokół projektu, czemu dumnie pomagam.

Mam nadzieję, że będziemy mogli spróbować ponownie w 2022, jako że Hanami domyślnie rozwiązuje większość problemów, które napotkaliśmy z Rails.

A dopóki to się nie stanie, będę ciężko pracował nad inicjatywą Hanami Mastery żeby pomóc rozwiązać wszystkie problemy, które napotkaliśmy podczas tego doświadczenia!