NestJS jest frameworkiem, którego fani Angular Love mieli już okazję poznać. Jeśli jednak nie miałeś jeszcze tej przyjemności sprawdź nasz ostatni artykuł.
Z uznaniem śledzimy także działalność twórcy Nesta – Kamila Myśliwca. Jest ona dla nas tak inspirująca, że postanowiliśmy skontaktować się z Kamilem, aby przeprowadzić z nim wywiad. Specjalnie dla Was, Kamil odpowiedział na aż 25 pytań!
Zapraszamy na pierwszą część wywiadu, w której wypytamy o historię oraz przyszłość Nesta, zahaczając także o Angulara.
Maciej Sikorski: Co Cię zmotywowało do stworzenia NestJS? Czy ludzie nie odradzali Ci pisania własnego frameworka?
Kamil Myśliwiec: Kiedy pod koniec 2016 roku rozpoczynałem prace nad Nestem nie stawiałem sobie jakichś konkretnych celów, nigdy nawet nie zakładałem, że projekt w ostateczności zyska tak wielką popularność i przerodzi się w pełnoprawny framework. Można powiedzieć, że z początku był to zwykły side-project nad którym pracowałem późnymi wieczorami. Nie miałem jednak żadnych oczekiwań, zwyczajnie kontynuowałem pracę wdrażając w życie kolejne funkcjonalności, które chciałbym aby framework z którego sam korzystam oferował, w sposób, który wydawał mi się „najlepszy”. Każda wzmianka na Twitterze czy gwiazdka na Githubie była swego rodzaju wyróżnieniem, powodem do radości i motywacją do dalszej pracy.
Czy NestJS był Twoją pierwszą próbą do pisania własnego frameworka? Jeżeli nie, to co sprawiło, że akurat tym razem udało się osiągnąć sukces?
Tak jak zapewne każdy programista, wielokrotnie tworzyłem swoje gotowe „boilerplate”, mikro-frameworki, które następnie wykorzystywałem w kolejnych projektach. Nest był jednak pierwszym frameworkiem o takiej skali, który zdecydowałem się stworzyć. Warto jednak podkreślić, że wstępne wersje/szkice projektu znacznie odbiegają od wersji końcowej. Były wzloty i upadki.
Mówisz że wstępne szkice znacząco odbiegały od wersji końcowej. Czy to znaczy, że początkowo wcale nie bazował na Angularze?
Od samego początku architektura i wiele założeń Nesta było inspirowane rozwiązaniami zastosowanymi w Angularze, ale faktem jest, że pierwsze prototypy nie posiadały feature’ów takich jak guardy czy interceptory. Ponadto, część dekoratorów miała nieco inne nazwy (przykładowo nie istniał dekorator @Injectable), pojawiały się delikatne nawiązania do Springa, dość szybko zresztą wyeliminowane 🙂 Nie było też CLI, które swoją drogą dość mocno bazuje na pakietach @angular-devkit.
Jakie jest Twoje doświadczenie z Angularem?
Moje pierwsze doświadczenia z Angularem, a właściwie jego „pierwotnej” wersji Angular.js sięgają, jeżeli dobrze pamiętam 2013 roku. Muszę jednak szczerze przyznać, że nigdy nie byłem entuzjastą ani zwolennikiem tej technologii. W kolejnych latach, zanim pojawiły się pierwsze wersje „Developer Preview” Angulara 2, znacznie chętniej sięgałem i pracowałem z Reactem. Pierwszy projekt, który wykonałem w nowym Angularze wykorzystywał wersję beta (co biorąc pod uwagę wiele „breaking changes”, które pojawiły się do czasu wersji finalnej, prawdopodobnie nie było najmądrzejszym wyborem). Od tego momentu aktywnie monitorowałem stan projektu i kiedy nareszcie opublikowana została stabilna wersja nadająca się do użytku, zacząłem korzystać z Angulara regularnie w projektach (choć jako ciekawostkę mogę dopowiedzieć, że do pierwszego komercyjnego projektu tworzonego w oparciu o “finalną” wersję Angulara dołączyłem jako programista React).
Co sprawiło, że NestJS tak mocno bazuje na Angularze?
Na przestrzeni lat wielokrotnie zdarzało mi się zmieniać język czy narzędzie z którym pracowałem (często było to podyktowane zmianą miejsca pracy lub projektu). Pomimo, że uważam, że warto jest nauczyć się, zagłębić w kilka różnych technologii celem nabrania doświadczenia, zrozumienia pewnych technik specyficznych dla danego języka i spojrzenia na programowanie z różnych perspektyw, tak również zauważyłem, jak wiele rzeczy jest koncepcyjnie podobnych, aczkolwiek nazwanych czy zaprojektowanych zupełnie inaczej. Niestety w tym przypadku, najczęściej nie niesie to zbyt wiele wartości dodanej (jeśli chodzi o naszą wiedzę), wynika to z decyzji twórców/zespołów i często powoduje, że spędzamy czas na uczeniu się jak osiągnąć „to samo” tylko w innej technologii, nie uczymy się technik, idei, a raczej staramy się zapamiętać API narzędzia, spędzając godziny w dokumentacji. Nest jest przykładem, że pomimo dwóch różnych światów (backend i frontend), zastosowanie podobnej nomenklatury, podobnych idei, czy bardzo zbliżonych rozwiązań (w tym przypadku zbliżonych do Angulara, którego nazewnictwo jest notabene bardzo generyczne) nie jest niemożliwe (nie wymaga wynajdywania koła na nowo). Poprzez zastosowanie podobnej terminologii i technik, Nest staje się też znacznie łatwiej przyswajalny dla ludzi, którzy posiadają już doświadczenie w Angularze i tworzy swego rodzaju most do świata backendu dla osób zainteresowanych tą dziedziną. Ponadto, w przypadku gdy pracuje się nad dwoma aplikacjami jednocześnie (FE i BE), wykorzystanie Nest i Angular jednocześnie znacznie zmniejsza „cognitive overhead”, powodując, że „przeskoczenie” z jednej aplikacji na drugą, zmiana kontekstu, nie wymaga tak dużego wysiłku.
Jakie największe wyzwania/trudności napotkałeś podczas tworzenia NestJS?
Wyzwań było wiele i ciężko byłoby mi wybrać te kilka najistotniejszych, aczkolwiek myślę, że taką podstawową trudnością jaką napotkałem była zmiana sposobu myślenia. Tworzenie typowych aplikacji końcowych znacznie różni się od projektowania bibliotek, szczególnie na taką skalę. Celem jest wytworzenie narzędzia, które maksymalnie usprawni pracę, zwiększy produktywność, narzuci pewną strukturę, jednocześnie nie ograniczając programisty, tak, aby nigdy nie doszło do sytuacji w której framework staje się uciążliwym ograniczeniem. Ważne jest, aby sprawić by rzeczy trudne stały się nieco prostsze, niekiedy mniej czasochłonne (a czasem wręcz przeciwnie), a jednocześnie w tym samym czasie nie wprowadzić ograniczeń w samym narzędziu. Znalezienie złotego środka pomiędzy elastycznością, a ustaleniem pewnych zasad/ram & abstrakcją jest wbrew pozorom bardzo trudnym zadaniem, a błędny wybór to najczęstszy powód niepowodzenia wielu podobnych narzędzi.
Czy były momenty, w których chciałeś porzucić ten projekt?
Zdecydowanie najtrudniej było z samego początku, kiedy nad Nestem pracowałem w głównej mierze wieczorami, nocami oraz weekendami, a w trakcie dnia poświęcałem się pozostałym obowiązkom, w tym pracy na pełny etat. Zdarzały się miesiące w których moja aktywność (w repozytoriach) spadała niemal do zera ze względu na natłok obowiązków. Nigdy nie doszło jednak do sytuacji krytycznej, w której rozważałbym całkowite porzucenie pracy nad frameworkiem.
Jak wygląda promocja własnego frameworka? Co robiłeś poza tworzeniem kodu, co sprawiło, że NestJS zyskał taką popularność? Nawet serwer na Discordzie poświęcony NestJS ma zawsze więcej aktywnych użytkowników, niż serwer poświęcony Angularowi.
Można powiedzieć, że w przypadku projektów OSS „wieść poniekąd niesie się sama”. Ja skupiłem się w głównej mierze na pisaniu kodu, do tego w celach marketingowych prowadzenia profilu na Twitterze i okazjonalnego publikowania artykułów, które następnie ktoś gdzieś zawsze podlinkował, np. na Reddit. Pozytywnie na wzrost rozpoznawalności wpłynęły również prelekcje na konferencjach czy organizowane warsztaty.
Od którego momentu uznałeś, że Nest jest wystarczająco dojrzały, aby wyjść z nim na konferencje?
Gdyby zależało to tylko ode mnie, to prawdopodobnie nigdy nie podjąłbym takiej decyzji (śmiech). Pod koniec 2018 roku skontaktował się ze mną Zack, organizator konferencji ngAtlanta w Atlancie. Powiedział „za cztery miesiące organizuję konferencję i chciałbym, żebyś się na niej pojawił”. Nie miałem wtedy ani wizy, ani nawet aktualnego paszportu. I od tego się wszystko zaczęło.
Jak bardzo stworzenie frameworka rozwinęło Cię jako programistę, managera?
Dla mnie osobiście jest to niezwykły, wręcz nieoceniony bagaż doświadczeń. Myślę, że największy impuls rozwojowy to przede wszystkim zetknięcie się ze społecznością programistów z całego świata. Publikacja tego typu projektu powoduje, że w pewnym sensie wystawiasz się na ewentualną krytykę z każdej strony. Stykasz się z wieloma pomysłami, koncepcjami, nie zawsze zgodnymi z Twoimi pierwotnymi założeniami. Wymaga to zarówno umiejętności argumentacji pewnych decyzji/założeń (jeżeli są słuszne), ale też i refleksji, samokrytyki, umiejętności dyskusji oraz koniec końców, również doskonalenia się na bazie doświadczeń innych osób.
Czy istnieje jakaś ciekawa historia związana z tym że kot został maskotką twojego projektu?
Brak! Prawdę mówiąc, jedynym powodem dla którego koty są swego rodzaju ikoną Nesta, jest moje, czasem nader przesadne zamiłowanie do nich. Koty to w większości istoty niezależne, indywidualiści/indywidualistki, bardzo charakterne zwierzęta, a to też poniekąd idealnie wpasowało mi się w wizję Nesta.
Jakie są plany na przyszłość dotyczące NestJS?
W krótkim terminie przede wszystkim wypuszczenie wersji v8, wyczekiwanej już od paru miesięcy. Nowy „major release” zawiera zarówno małe usprawnienia (m.in. automatyczną inferencję typów nawet przy wykorzystaniu „dot notation” dla pakietu „config”, możliwość buforowania logów, czy subskrybowanie tego samego zdarzenia równolegle z poziomu kilku różnych kontrolerów), jak i nowych funkcjonalności, w tym ułatwienia dotyczące wersjonowania aplikacji oraz możliwość leniwego ładowania modułów „at runtime” (choć mechanizm ten znacznie różni się od tego, z czym można spotkać się w Angularze). Pojawią się również małe usprawnienia do dokumentacji, w tym nowy rozdział, który zagłębia się w tematykę serverless (był to jeden z najbardziej popularnych issues w repozytorium). W długim terminie oczywiście dalszy rozwój frameworka i całego ekosystemu, który go otacza.
Odpowiedź została udzielona 23.06.2021r. Wersja 8 NestJS jest już dostępna. Więcej o niej możecie przeczytać tutaj.
Czy jest jakaś rzecz którą chciałbyś aby NestJS “osiągnął”? Czy masz przed oczami jakieś kolejne milestony, albo punkt docelowy/marzenie?
Nie mam jakichś sprecyzowanych i daleko idących oczekiwań, aczkolwiek pół żartem pół serio zawsze śmiałem się, że tym takim głównym punktem docelowym byłoby zrównanie się ze statystykami pobrań (NPM) Nesta z Angularem 🙂
Jak społeczność NestJS może pomóc w rozwijaniu swojego ulubionego frameworka i utrzymaniu jego roadmapy?
Przede wszystkim poprzez bezpośrednią pomoc, czyli przykładowo rozwiązywanie problemów raportowanych przez społeczność frameworka w postaci Pull Requestów. Część z nich nie jest zbyt czasochłonna i nie wymaga opanowania/zrozumienia kodu źródłowego całego narzędzia, a raczej zaledwie kilku jego fragmentów. Podobnie w przypadku propozycji delikatnego usprawnienia danej funkcjonalności – warto rozważyć, czy po utworzeniu issue nie warto spróbować zaproponować rozwiązanie na własną rękę, szczególnie jeżeli wymaga ono modyfikacji zaledwie kilku linii kodu.
Czy fakt, że twórca NestJS jest Polakiem wpływa jakoś na wsparcie dla polskich programistów NestJS? Czy mogą oni liczyć na jakiś ekskluzywny content (nie licząc tego wywiadu 😉 )? Niektórzy postulują za polską wersją dokumentacji, na wzór ekipy od Vue.js.
Wielokrotnie zastanawiałem się nad utworzeniem polskiej wersji dokumentacji i bardzo chciałbym, aby kiedyś było to możliwe. Główną barierą, która na ten moment uniemożliwia posiadania wielu wersji językowych jest czas, jaki pochłania nie tylko przetłumaczenie wszystkich rozdziałów, które zostały napisane do tej pory, ale również (a może i przede wszystkim) dalsze utrzymywanie & aktualizowanie dokumentacji, wraz z wprowadzanymi poprawkami czy dodawanymi przykładami/rozdziałami. Generalnie prowadzenie dokumentacji wielkiego projektu jest jednym z najbardziej czasochłonnych elementów rozwijania & prowadzenia frameworka i stąd właśnie na ten moment, Nest oferuje jedynie wersję angielską. Pojawiły się również propozycje napisania polskiej książki i nie ukrywam, że byłoby to bardzo ciekawe wyzwanie, ale i w tym przypadku przypuszczam, że bardzo angażujące i wymagające poświęcenia. Oczywiście zawsze chętnie też pojawiam się na mojej ulubionej polskiej konferencji, NgPoland & JsPoland (stąd pozdrowienia dla Darka!) i tam też można mnie spotkać
Pingback: Wywiad z Kamilem Myśliwcem cz. 2 - Angular.love