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ę.

Ale pojawiają się też rzeczywiście projekty, w których warto zastosować właśnie podejście Monorepo. No i na przykład ostatni projekt, w którym aktualnie pracujemy, to jest architektura mikroserwisowa, mikrofrontendowa, ale oparta właśnie o Monorepo, gdzie tak naprawdę jest dość duża separacja, dość duża separacja odpowiedzialności pomiędzy poszczególnymi aspektami, ale ma to oczywiście swoje wady. W moim rozumieniu, z mojego doświadczenia wynika taki wniosek, że często podejmując decyzję o tym, czy chcemy wybrać Polirepo czy Monorepo, nie zastanawiamy się troszeczkę nad tym, jaka przyszłość może czekać nasz projekt, kiedy podejmiemy różnego rodzaju decyzje.

Tam też zwróciłeś uwagę podczas jednej z naszych rozmów, że te największe firmy, największe projekty na świecie od lat korzystają z Monorepo. A w tych mniejszych bardzo często szło się za hype'em, a hype często był mocno związany właśnie z Polirepo, właśnie z podejściem takim rozproszonym. No i teraz mamy tak naprawdę dużo plusów, dużo minusów. Dla mnie największym plusem w przypadku, jeśli chodzi o Monorepo, jest to, że mamy tak naprawdę jedno źródło kodu, Tak naprawdę mamy wszystko w jednym miejscu. Nie musimy rozpraszać swojej uwagi pomiędzy poszczególnymi repozytoriami, poszczególnymi projektami.

Oczywiście ma to też swoją wadę. Główną będzie to, że raczej musimy pracować wspólnie przy dużym projekcie, dość złożonym. Często utrzymanie go jest troszeczkę bardziej utrudnione, ponieważ mamy więcej problemów związanych chociażby z mergżowaniem różnych funkcjonalności. Mogą wystąpić różne case'y. Nie możemy wybierać Wybierać chociażby różnych wersji bibliotek dla tego samego rozwiązania, no i raczej pracujemy w jednym języku, w jednej technologii. A ze swojej strony, jak na to patrzysz? Myślę, że jest to temat szeroki jak rzeka u nas w projekcie, w którym ja aktualnie pracuję. Podejście jest dość ciekawe, bo w jednym z projektów, w którym jestem jest to Monorepo.

Jest to Monorepo, które zostało założone bardzo dawno temu. I w tym Monorepo znajduje się jeszcze jedno Monorepo frontendowe. I dodatkowo też w związku z tym, że jedna drużyna zajmuje się najnowszą częścią naszej aplikacji, zostało to właśnie wydzielone jako Polirepo, więc mam całkiem niezły obraz tego, jakie są plusy i minusy jednego i drugiego podejścia. I tak na szybko, aktualnie w mojej pracy bym powiedział, że to podejście Monorepo ma ogromne plusy. Ma trochę minusów, ale jednak większość same plusy, w przeciwieństwie do tego, co oferuje Polirepo. Okej. Właściwie bardziej mnie interesują minusy niż plusy.

To według ciebie jest złego tak naprawdę w Monorepo, bo o plusach myślę, że jeszcze sobie porozmawiamy, natomiast te minusy chyba są trudniejsze do znalezienia. Mhm. Znaczy, myślę, że wiesz... Zależy, ale zgadzam się z tobą, że może są one mniej widoczne trochę na pierwszy rzut oka, chociaż też domyślam się, że zależy z kim rozmawiasz i kogo pytasz. Ale w naszym przypadku jakby taka decyzja została podjęta z tego powodu, że w momencie kiedy mamy duży team i wszyscy próbujemy merge'ować go do jednego brancia, powiedzmy do mastera, to zaczyna się to robić problem i trochę głupi się to wszystko w tym gicie. Wszystkie komity, zarządzanie tym odpowiednio pull requestami jest trochę problematyczne, więc takie Polirepo właśnie daje to, że od razu widzimy, co się dzieje.

Każdy comment, który trafi do mastera jest testowany tak jak każda inna część aplikacji. Ok. Ja widzę chyba jeszcze dwa minusy. Pierwszy z nich to jest wersjonowanie. Trudno... Tak naprawdę wydaje mi się, że tutaj... Właściwie to bym chyba wyrzucił na sam początek gdzieś, że jest spory problem tak naprawdę z wersjonowaniem poszczególnych części w Monorepo. Więc tak naprawdę gdzieś ten case bym jeszcze ujął jako minus. I drugi case, o którym też pomyślałem teraz, właściwie mi wpadł do głowy, to jest problem z ograniczeniem dostępu do poszczególnych części.

Gdybyśmy na przykład chcieli ograniczyć, że dla pewnego zespołu jest tylko dostęp do pewnej części tego repozytorium, więc tak naprawdę tutaj mógłby też się pojawić problem. Więc To takie może niepopularne myślenie tak naprawdę, jeśli chodzi o te ograniczenia dostępu, ale w zasadzie jakby tak na to spojrzeć z perspektywy bezpieczeństwa, to było bardzo potrzebne i bardzo konieczne i wydaje mi się, że w zasadzie dość istotny punkt. Jeżeli mamy na przykład zespoły, wiele zespołów, które razem pracują na jednym projekcie i razem chcą Osiągać coś to w takim Monorepo sama ilość deweloperów jest problemem, ale też brak możliwości ograniczeń dostępu do pewnych jego części też może być w jakimś tam stopniu problematyczne.

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.

Ale to samo może się wydarzyć też w zwykłym Monorepo tak naprawdę. Wiesz, duplikacja kodu... Wydaje mi się, że duplikacja kodu Możemy zrobić w każdym miejscu tak naprawdę. Jedynym argumentem, który widzę w tym konkretnym minusie za Monorepo jest to, że może w Monorepo łatwiej to wychwycić. Tak, też myślę, że zdecydowanie łatwiej jest sobie z tym poradzić, bo już to, co istnieje dookoła tego naszego Monorepo daje nam to, że możemy sobie wydzielić ten kawałek kodu i podzielić z innych częściach naszej aplikacji. Ja pomyślałem jeszcze o jednym minusie Monorepo. O zależnościach. Bo w przypadku Polirepo, jak mamy wydzielone niezależnie moduły, czy też serwisy do oddzielnych repozytoriów, to jest o wiele trudniej nam odwoływać się na zależności, które istnieją w zewnętrznych modułach.

Natomiast w Monorepo mamy wszystko w jednym codebase. Więc mając wszystko w jednym codebase, tak naprawdę ogranicza nas tylko ścieżka do pliku. I ja na przykład ten problem widzę w projekcie, w którym jestem. Mamy tak jakby dwie aplikacje, które są w jednym repo. Ta jedna aplikacja jest starsza od tej, którą aktualnie ja wytwarzam. I często było tak, że część modułów, które zostały wszyte w tą pierwszą aplikację, nigdy nie zostało wydzielonych do jakiegoś shared catalogu, shared directory czy cokolwiek innego, jakiegoś commona. To de facto powoduje, że jedna aplikacja, która jakoby jest niezależna, korzysta z zależności, jak ma po prostu rzeczy, które zostały wpisane w tą pierwszą aplikację.

I w zasadzie wydaje mi się, że akurat te błędy architektoniczne o wiele łatwiej popełnić Monorepo niż Polirepo. Te dwa, o których wspomnieliśmy. To co? Jeszcze te minusy Polirepo? Jasne, możemy o nich pogadać. Przychodzi ci coś jeszcze do głowy? Utrzymanie. Zdecydowanie case utrzymania projektu w przypadku Polirepo, bo z jednej strony mówili, że Monorepo jest kosztowne, jeśli chodzi o Continuous Integrations. Zdecydowanie zgadzam się, bo codebase jest dość duży, to są gigabajty danych często, więc zbudowanie takiego, utrzymanie w procesie, czy też przejście przez taki proces w ramach jednego pomergu, czy też w ramach jakiegoś tam pipeline'a,

1.02 2.02 Bardzo często, jak to w architekturze mikroservice'owej, wymaga utrzymania wielu repozytorów, wprowadzania zmian. Wielu często, jeżeli mamy jakieś rozbite funkcjonalności, że zmiana wymaga zmiany w iluś tam modułach, kilkunastu modułach, wówczas wprowadzenie takiej zmiany jest dość kosztowne i utrzymanie tego jest dość trudniejsze, dużo trudniejsze mógłbym nawet powiedzieć, Niestrobenia tego w Monorepo. I więc to byłaby wada na przykład Polirepo.

Ja bym tak na to patrzył. Więc tak naprawdę zarządzanie zależnościami na pewno jest ciekawsze z perspektywy Polirepo, aczkolwiek Monorepo też ma swój plus tutaj według mnie. Współpraca to jest to, o czym rozmawialiśmy. Czyli tak naprawdę ten codebase jest z jednej strony fajnie, że wszyscy mamy w Monorepo dostęp do tego jednej bazy kodu i razem nad tym pracujemy, dzięki czemu jest łatwiej to rozwijać, poniekąd jest łatwiej to rozwijać, ale z drugiej strony mamy ten problem, że nie mamy tej takiej separacji i czasami wchodzimy sobie w drogę. DevOpsowanie, no to tutaj

W tym temacie to już chyba porozmawialiśmy, czyli wydaje mi się, że rzeczywiście zgadzamy się co do tego, że w zależności od tego, na co położymy większy nadzór, czy na koszt tej CD, wtedy ten koszt, jeżeli chcemy, żeby był niższy, Polirepo będzie fajniejszym rozwiązaniem. Ale jeśli na przykład chodzi o utrzymanie spójności, to wydaje mi się, że Monorepo będzie bardziej praktyczny. Jeszcze jest jeden temat. Jeszcze są właściwie dwa tematy, które powinniśmy poruszyć. I teraz jeśli chodzi o plusy też plusy tak naprawdę Polirepo, to myślę, że warto wspomnieć o rozmiarze paczek. Czyli tak naprawdę tak możemy tak technologiczne możemy sobie wydzielić bardzo precyzyjnie per moduł.

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.

Jeszcze wracając trochę o propos właśnie tego dzielenia się kodów Monorepo między deweloperami, to myślę, że też ogromnym plusem jest to, że właśnie w momencie, kiedy posiadamy Monorepo, chcąc czy nie chcąc, deweloperzy nawet pracując nad jakimś wycinkiem aplikacji, poznają jej jakieś wspólne części i łatwiej ich można angażować w inne fragmenty naszej aplikacji. Bo w momencie, kiedy mamy to podzielone na Polirepo i wkładamy dewelopera na inny projekt, powiedzmy, że mamy aplikację front-endową i chcemy go przełożyć na aplikację mobilną, to wtedy jest ciężej w momencie, kiedy właśnie mamy tą architekturę Polirepo, czy też mamy Polirepo, W momencie kiedy mamy Monorepo, w momencie kiedy nasz deweloper zaznajomił się już tą bazą kodu, o której mamy, widział jakieś wspólne fragmenty, powiedzmy też pracował nad biblioteką UI, wtedy jest mu znacznie łatwiej się wgryźć w tą aplikację mobilną, niż w momencie kiedy musiałby ściągać całe repozytorium i od nowa się tego uczyć.

Tak na dobrą sprawę. A w momencie kiedy mamy Monorepo, Już mamy praktycznie dewelopera gotowego, bo on otwiera inny folder i zmienia trochę inne pliki. Tutaj bym jeszcze dodał jedną rzecz, bo tak teraz mi wpadło, że w momencie, w którym mamy Polirepo i mamy tak naprawdę dewelopera, który często musi, nie wiem, weekendowca chociażby, to najbardziej klasyczne. Mamy weekendowca, który potrzebuje pięciu czy sześciu serwisów U siebie lokalnie postawionych po to, żeby ten system zadziałał. Więc musi mieć bazę postawioną, musi mieć postawione 3-4 serwisy, musi mieć często postawiony jakiś frontend lokalnie, żeby umieć sobie testować, ewentualnie będzie testował na jakimś swaggerze, albo postmanie, albo czymkolwiek innym.

Ale w zasadzie najczęściej musi mieć wiele projektów postawionych, uruchomionych jednocześnie na różnych portach i najczęściej samodzielnie musi o to zadbać. Żeby to działało i funkcjonowało. W przypadku Monorepo, to też będzie duży plus dla Monorepo, jak wszystko jest razem, to możemy sobie fajne skrypty napisać, które będą nam to ogarniały. I tak naprawdę za pomocą jednego polecenia uruchamiali, stawiali wszystkie serwisy, uruchamiali wszystkie niezbędne systemy, I tak naprawdę będzie to łatwiejsze w utrzymaniu, czy też w przebudowywaniu. Nie będzie trzeba pamiętać, że ok, tu zabijam proces, tu zabijam proces, tu zabijam, tu zabijam, ten uruchamiam, ten uruchamiam, bazę czyszczę, pach, jeszcze raz. W przypadku, kiedy mamy to razem, jest to o wiele łatwiejsze w utrzymaniu.

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ć.

Okej, zgadzam się, 100%. Więc odpowiadając, czy jestem zwolennikiem, czy przeciwnikiem, sam nie wiem. Bo wydaje mi się, że oba te zastosowania mają swoje plusy i minusy. I na pewno w przypadku, kiedy mamy bardziej rozproszony system, dość duży system, to architektura mikroserwisowa i Polirepo jest ciekawszym rozwiązaniem. Natomiast w momencie, kiedy mamy duży zespół i ten projekt tak naprawdę może być trzymany razem, I zależy nam tak naprawdę na spójności z jednej strony, nie mamy tego procesu CI-CD tak bardzo złożonego, to wtedy Monorepo jest świetnym rozwiązaniem. I w zasadzie sprowadza się to do tego, że każdy z tych podejść jest fajny, dać plusy i minusy, żeby po prostu podjąć dobrą decyzję, która będzie dobra z perspektywy nie tyle dewelopera,

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?

Wchodzą ci do głowy jakieś takie proste miejsca, też zasady, którymi byś się posługiwał właśnie patrząc na projekt? Potrałbyś szybko stwierdzić, że to powinno być Monorepo, a to powinno być Polirepo? Szybko nie. Ale na pewno spojrzałbym na kilka przesłanek. Jedną z przesłanek byłoby doświadczenie programistów, których mamy w zespole. I wydawać by się mogło, że Polirepo jest trudniejsze w utworzeniu, w zarządzaniu, ale w zasadzie w moim odczuciu o wiele istotniejsze i większe wymagania względem deweloperów stoją w momencie, kiedy decydujemy się na Monorepo. Monorepo wymaga o wiele większego Wiele większej samodyscypliny i samozaparcia, jeśli chodzi o rozwijanie tego projektu.

Myślę, że formalizacji. Formalizacji, dokładnie. Bo z jednej strony okej, mamy w Monorepo wszelkiego rodzaju lintery będziemy mieć, więc te wszystkie style linty, s-linty, ts-linty i tak dalej i tak dalej, plus będziemy mieć jakieś pretiery i inne rzeczy po stronie frontendowej, które sprawią, że ta spójność kodu stylistycznie i funkcjonalnie będzie na wysokim poziomie powiedzmy, natomiast nadal Będzie to wymagało zrozumienia całości projektu jako takiego, po to, żeby wiedzieć, czy dana funkcjonalność być może powstała już, wiedzieć, gdzie szukać. Będzie wymagała dużego rozeznania pomiędzy frontendem, backendem, czy też mobilkami, bo często jest tak, że w tych Monorepo znajdują się wszystkie projekty naraz.

Zarówno backend, frontend, jak i mobilka. I to de facto sprowadza się do tego, że ta To doświadczenie programisty musi być na dość wysokim poziomie. W przypadku Polirepo, okej, on zna tylko swoją działkę, tym się zajmuje, nie wiem, jest tylko frontendowcem, zna tylko Reacta, więc siedzi w Reactie i siedzi w repozytorium Reactowym, nie musi wiedzieć nic więcej, co się tam dzieje. W przypadku, kiedy wchodzi w to głębiej i musi na przykład postawić sobie projekt weekendowy, no to to już często robią się W przypadku Polirepo tak naprawdę postawi i zapomni. W przypadku Monorepo będzie musiał tym zarządzać w jakiś sposób.