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.

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.

Okej, to się zgodzę, to się zgodzę. W zasadzie tutaj warto też chyba podać, że w przypadku, kiedy mamy taką Taką sytuację, gdzie jest dosyć duży zespół i mamy to jedno repo, które zajmuje się wszystkim, to ten problem, o którym wspominasz, czyli de facto problem z merge'owaniem kodu, można pewnie rozwiązać poprzez jakąś dobrą politykę zarządzania branczami, tworzenia branczy i zachowania odpowiedniej kolejności merge'owania tego. Ale to jest jednak dodatkowa procedura, którą trzeba sobie wdrożyć, więc zdecydowanie tak. A jakieś inne minusy? To prawda i myślę, że kolejny minus z tym trochę powiązany i to też kolejny argument, dlaczego my właśnie w tym nowym projekcie zdecydowaliśmy się jednak na podejście Polirepo, to są koszty związane z TI i z E.

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.

I kończymy z jakąś tam straszną sytuacją, gdzie musimy utrzymywać dwa różne fragmenty tego samego kodu w dwóch różnych miejscach. Okej, a nie wydaje Ci się, że to jest problem bardzo związany z zaprojektowaniem samej aplikacji? Taki problem bardzo stricte architektoniczny? No bo jakby nie spojrzeć, Kiedy myślimy o Polirepo, bardzo często myślimy o architekturze mikroserwisowej. Mikrofrontendy czy mikroserwisy na backendzie to jest jednak podejście, które jest często dość pożądane i często odchodzi się od tych wielkich, monolitycznych aplikacji. Polirepo w takim ujęciu bardzo często jest dość mocno powiązane z taką architekturą mikroserwisową.

Tyle tylko, że w przypadku W takiej architekturze mikroserwisowej musimy mieć dość precyzyjnie wydzielone odpowiedzialności. Jeśli tego nie zrobimy, to możemy, tak jak powiedziałeś, możemy mieć sytuację, w której będziemy mieć wiele różnych serwisów, które robią podobne rzeczy lub te same. Ale tak z perspektywy budowania takiej aplikacji, to jest błąd po prostu architektoniczny. Tak by się wydawało. Więc w zasadzie takie Polirepo, gdzie mamy różne, niezależne, samodzielne wręcz moduły, systemy, serwisy, byłoby dość ciekawe tak naprawdę i wydaje się dosyć dobrym pomysłem.

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.

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.

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.

I będziemy je rozwiązywać. Jeżeli będziemy mieć jakieś wspólne pliki, które zawsze są dotykane podczas merge'a, to każdy merge będzie dotykał tych plików i często one będą konfliktowały, więc to może być frustrujące. I to jest na pewno duży plus Polirepo. Wydaje mi się, że też odwrotność tego, co też już powiedzieliśmy, czyli zarządzanie bezpieczeństwem, czyli bezpieczeństwo i zarządzanie dostępem dla różnych poziomów, dla różnych części aplikacji. Wydaje mi się też, że łatwiej użyć w Polirepo właśnie tych DevOps Tools, zresztą o tym też wspominałeś.

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.

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.

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.

Więc na pewno zwróciłbym uwagę na doświadczenie zespołu. Drugi aspekt, którego bym dotknął, to jest wielkość projektu jako takiego, czy też jego złożoność. I w zasadzie zadałbym pytanie, O jak bardzo mamy rozbity technologicznie ten projekt. Na przykład, czy mamy wiele języków programowania w ramach tego projektu. Czy część robimy w dotnecie, część w Javie, a część robimy na przykład w Javascriptie. Wówczas, pomimo tego, że istnieją rozwiązania, które pozwalają tym zarządzać, po stronie, w akcji Monorepo, wydaje mi się, że ciekawsze mogłoby być wówczas jak Polirepo.