1.02 (2) Monorepo vs Polirepo

Cześć! Witam Was serdecznie w kolejnym odcinku naszego podcastu Piwnica IT. Dzisiaj razem z Wojtkiem spotkaliśmy się, żeby porozmawiać sobie o temacie, który poniekąd jest dość łatwy, ale jednocześnie może być dość skomplikowany. I narobić nam troszeczkę problemów na późniejszych etapach, kiedy nasz projekt, z którym pracujemy, się rozwija. Otóż chcielibyśmy poruszyć sobie odwieczne pytanie, odpowiedzieć na odwieczne pytanie. Monorepo czy Polirepo? O tym jest dzisiaj nasz odcinek. Ja jestem Mateusz. Bardzo miło mi was gościć w naszym podcaście. Jest ze mną Wojtek. Cześć Wojtku. Cześć wszystkim. No to co Mateuszu, może opowiesz nam o swoich doświadczeniach. Prawda jest taka Wojtku, że zarówno Monorepo jak i Polirepo spotykamy w obu przypadkach i prawda jest też taka, że w większości przypadków deweloperzy chyba starają się wybierać tą architekturę bardziej rozproszoną, gdzie mamy tą architekturę bardziej mikroserwisową i zdecydowanie w wielu przypadkach w projektach, w których ja do tej pory uczestniczyłem był spory nacisk na to, żeby iść w tą stronę.

Zdecydowanie się z tym ukaza, Mateusz. Myślę, że to jest bardzo dobry punkt i potrafię sobie wyobrazić, że w takich miejscach jak np. bank, 2.03 2 Monorepo vs Polirepo. Myślę, że tutaj też jest dość dużo ciekawych dyskusji, które można mieć na temat tych minusów Polirepo.

Wydaje mi się, że w przypadku Polirepo byłoby to trudniejsze do zrobienia. Jest to ciekawy argument, ale tutaj też znowu myślę, że to jest kwestia architekturalna. I znowu błąd, który został popełniony trochę w innym miejscu. Zgadzam się z tobą. No tak, to prawda. W momencie, kiedy łatwiej się dzielicie tymi aplikacjami w projekcie, zdecydowanie może cię kusić, żeby to zrobić w miejscu, w którym to nie jest najlepszy pomysł, żeby to zrobić. No ale myślę, że to jak wiesz Mateusz, z twojego długiego doświadczenia każde rozwiązanie ma swoje plusy i swoje minusy. Tak, oczywiście. Cały czas mówimy o tym, że gdzieś popełniono błędy.

Możemy sobie podjąć decyzję O wersjach, które chcemy wykorzystywać w ramach poszczególnych serwisów. Możemy podjąć decyzję, w jakim języku te poszczególne fragmenty chcemy pisać. Więc tak naprawdę z perspektywy Polirepo mamy większą dowolność, większą swobodę. W zasadzie są też różnego rodzaju podejścia o tym, że w Monorepo też możemy Na przykład z wykorzystaniem frameworków. A co ty myślisz w zasadzie specyficznie o dobieranie stacków, czy też wersji poszczególnych? Jak byś to rozwiązał w Monorepo może? Bo już sam nie wiem w zasadzie, czy ty jesteś zwolennikiem, czy przeciwnikiem. Ja też jestem pogubiony, Mateuszu, czy ty jesteś zwolennikiem czy przeciwnikiem.

Zgadzam się z tobą Mateuszu i też myślę, że nawet już nie idąc w jakieś rzeczy takie jak skrypty, a już myśląc o samym wersjonowaniu, to domyślam się, że bardzo szybko może dojść do takiej sytuacji, kiedy mamy dość dynamiczny projekt, w którym są robione jakieś breaking changes. W momencie, kiedy musimy martwić się o to, czy to Polirepo ma wersję 0.1, bo ta wersja 0.1 działa tylko z serwisem, który ma wersję 0.2, tak, i tak dalej, i tak dalej. I sami musimy właśnie w tej architekturze, powiedzmy, czy właśnie w tym podejściu Polirepo, sami zadbać o to, żeby mieć odpowiednią wersję. W momencie, kiedy mamy Monorepo, teoretycznie powinniśmy móc pobrać sobie, tak, pobrać to repozytorium i możemy sobie to deployować.

Ile z perspektywy projektu? Nawiążę trochę do tego, o czym rozmawialiśmy ostatnio, czyli ten taki developer experience. Przypuszczam, że w przypadku Monorepo może być ciekawszy developer experience, jeśli chodzi właśnie o budowanie, stawianie projektu, to o czym wspomniałem, bo to będzie zdecydowanie przyjemniejszy proces, łatwiejszy w osiągnięciu niż W przypadku Polirepo, ale z drugiej strony Polirepo może być, może mieć fajniejszy developer experience jeśli chodzi o wytwarzanie oprogramowania. Mateuszu, czy mógłbyś powiedzieć, albo czy widzisz właśnie takie jakieś jasne wskazówki, takie jasne guidelines, gdzie właśnie to Monorepo to byłoby idealne rozwiązanie, albo to Polirepo byłoby idealnym rozwiązaniem?

W ujęciu tego, że frontend tak naprawdę jest pojedynczym repozytorium? Czy też odwrotnie? Jak backend patrzy na ten frontend? I czy coś by zmieniło, gdyby te zespoły pracowały razem, w jednym tak naprawdę Monorepo? Bardzo dobre pytanie, Mateuszu. Myślę, że w dzisiejszych czasach ogólnie coraz bardziej się ceni właśnie taki podział już nie wertykalny, tylko horyzontalny i tworzy się raczej Drużyny, które potrafią dostarczyć feature od początku do końca, a nie jest on podzielony na właśnie frontend i backend.

Wykorzystują różne technologie, które wykorzystują zarówno różne języki, ale też różne frameworki czasami. Przenikają się te rzeczy pomiędzy sobą. W przypadku, to co już ustaliliśmy, w przypadku Polirepo jest to zdecydowanie łatwiejsze w utrzymaniu wówczas. Ale czy Monorepo staje się niedostępne, kiedy mamy wiele różnych języków? Wydaje mi się, że nie, Mateuszu. I tak jak już rozmawialiśmy przed naszym nagraniem, że takie firmy jak Google czy inni giganci z Silicon Valley tak naprawdę od zawsze mają Monorepo i od zawsze też tworzą praktycznie narzędzia do zarządzania właśnie tymi swoimi Monorepo, które zdecydowanie nie składają się tylko z jednego języka.

Tutaj tych narzędzi jest dość wiele. Google, o którym wspominałem, korzysta i stworzył takie narzędzie, które nazywa się Bazel. Niestety jest ono dość skomplikowane. Z kolei Microsoft ma Rush, o ile dobrze pamiętam. Więc zdecydowanie nawet w momencie, kiedy żyjemy w tej architekturze mikroserwisowej, o której też wspominałeś Mateuszu, to nie jest tak, że musimy rezygnować z innych języków czy z innych frameworków. Dalej możemy korzystać z tych dobrodziejstw Monorepo, dając sobie tą wolność egzystencji w architekturze mikroserwisów i wolności, którą one nam dają. Okej, no ale jeżeli spojrzymy na to głębiej, to żeby utrzymywać w jednym Monorepo wiele języków najczęściej musielibyśmy skorzystać z jakiegoś dodatkowego narzutu w postaci jakiegoś frameworka najczęściej.

I domyślam się, że jest to rozwiązanie. Chociaż no myślę, że jest to ogromny plus. Chociaż no to tak jak z każdym narzędziem, Mateuszu, wiesz jak to jest, tak? No to są znowu zawsze plusy i minusy. Rzeczywiście otwieramy się na bugi. Może być też tak jak z Learnom, prawda? Która została być wspierana, a koniec końców została kupiona przez Enixa. Tak naprawdę przez długi czas była w dość słabym stanie. To też ryzyko, z którym musimy się mierzyć. Ale też była bardzo mocno wykorzystywana, szczególnie do wersjonowania szczególnych podczęści. Tym się najczęściej spotykałem. Do tworzenia szczególnie jakichś systemów szablonów, jakieś UI-owe. Gdyby nie takich komponentów wewnętrznych w projektach, to Lerna bardzo często się z tym pojawiała.

Czy masz jakiś pomysł, jaka jest przyczyna tego, że Monorepo od lat jest popularne wśród tych gigantów, a wśród mniejszych firm? Raczej było to Polirepo, Wiesz co, myślę Mateuszu, że też chętnie przede wszystkim poznam twoje zdanie na ten temat. Ja mam dwa pomysły, dlaczego może tak to wyglądać. Pierwszy pomysł, który przychodzi mi do głowy, czyli te narzędzia, o których wspominałem, między innymi Rush czy Bazel, są bardzo skomplikowane. I myślę, że tak naprawdę dopiero od niedawna pojawiają się takie narzędzia w środowisku właśnie javascriptowym, o którym tutaj głównie rozmawiamy, które znacznie ułatwiają tworzenie tych monorepo właśnie mając na względzie to środowisko javascriptowe.

Więc wydaje mi się, że Mniejsze podmioty dopiero teraz zaczynają zauważać wady Polirepo i starają się też w jakiś tam sposób może zminimalizować ryzyko tego, że jakiś projekt zostanie zapomniany albo że będzie trudniejszy w utrzymaniu. No tak, i też pewnie wchodzą tutaj rzeczy, o których wspominaliśmy dzisiaj, czyli refaktoryzacja, lepsze radzenie sobie z długim technicznym łączem, o którym ty pośrednio właśnie mówiłeś, Mateuszu. Po prostu możliwość szybszej zmiany w wielu miejscach i łatwiejszego kontrolowania tych zmian niż w momencie, kiedy mamy takie Polirepo. Wojtek, chciałbyś jeszcze coś dodać w tym temacie?

Jeśli chodzi o Monorepo czy Polirepo, myślę, że ostatnie pytanie, które przychodzi mi do głowy, Mateuszu, dzisiaj do ciebie jest takie, że właśnie w tym środowisku javascriptowym, w którym my istniejemy, na jakie narzędzia ty byś się zdecydował? Ja personalnie, jeśli chodzi o Monorepo, wybrałbym aktualnie Turborepo. Nie wiem, czy miałeś do czynienia, ale jest to świetny projekt, też sponsorowany przez Vercela, o którym ostatnio rozmawialiśmy. I myślę, że ogromną jego zaletą jest to, że jest bardzo prosty. Nie daje dużo, ale jakby daje to, co jest najważniejsze w mojej opinii. Więc właśnie wybrałbym Turbo Repo w porównaniu do takiego NX, o którym też dzisiaj wspominaliśmy, który jest dość skomplikowany i setup takiego projektu, nie wiem, czy miałeś okazję Mateuszu, jest dość przerażający, bo ilość konfiguracji, którą zapewnia taki NX, który zapewnia też dużo wspaniałych narzędzi integracji i wtyczek, chociażby do samego wierzyła Studio Code, no jednak ta ilość konfiguracji, szczególnie na samym początku, jest naprawdę przerażająca.

1.02 2 Monorepo, Mateusz Jabłoński. No istnieje i daje sobie całkiem nieźle radę. Chociaż tutaj ciekawe są też rozwiązania typu NPM Workspaces i Yarn Workspaces, z których Turbo Repo korzysta. Myślę, że to też jest ciekawe, że nawet NPM czy też Yarn zaczynają wspierać jakby natywnie właśnie to podejście Monorepo.

Dostarczają narzędzia, żeby łatwiej było je tworzyć. Ale z drugiej strony, z tego co wiem, Turbo Repo zostało zaprojektowane typowo dla Monorepo. Ale po pewnym czasie dołożyli tak naprawdę wsparcie dla Polirepo również. Więc w tym momencie Turbo Repo ma też wsparcie dla Polirepo. To ciekawostka, nie słyszałem o tym. Jeśli tak mówisz Mateuszu, to może rzeczywiście tak jest, ale... Powiem Ci szczerze, nie pracowałem z tym narzędziem. Dlatego też zapytałem o to, czy nie myślisz, że to jest hype. U nas w projektach nie było do tej pory jeszcze możliwości za bardzo, żeby to gdzieś wykorzystać. Natomiast trochę czytałem jakiś czas temu i właśnie spotkałem się z tym, że dodali po pewnym czasie ten support, to wsparcie dla Polirepo również.

No to ciekawostka dla mnie. Nie spotkałem się z taką informacją. Dla mnie jeden wniosek. Jeden wniosek, który to też trochę podsumowuje. Zobacz, narzędzie dla Monorepo daje wsparcie również dla Polirepo. Czyli de facto, jakby na to spojrzeć, jakby na to nie spojrzeć, oba te podejścia są spoko. Tylko każdy ma swoje zalety i wady i każdy ma inne zastosowanie. Zgadzam się z Tobą w 100% i zastanawiam się jeszcze, czy myli Tobie Turborepo z Turbopakiem. Nie. Nie? Nie. Okej. No to jeśli się nie myli, to okej. I myślę, że zgadzam się odnośnie tego wniosku, czy też podsumowania, które przedstawił Mateuszu, że właśnie czy to Monorepo, czy Polirepo, jedno i drugie ma swoje plusy i minusy i najważniejsze jest to, jak w końcu je zastosujemy.