Mateusz: Cześć, witam was serdecznie w kolejnym odcinku naszego podcastu Piwnica IT. Dzisiaj razem z Wojtkiem spotkaliśmy się, żeby porozmawiać 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 w którym pracujemy się rozwija. Otóż chcielibyśmy 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.

Wojtek: Cześć wszystkim. No to co Mateuszu, może opowiesz nam o swoich doświadczeniach?

M: Prawda jest taka Wojtku, że spotykamy zarówno monorepo, jak i polirepo. W większości przypadków developerzy chyba starają się wybierać architekturę bardziej rozproszoną, gdzie mamy tą architekturę bardziej mikroserwisową i zdecydowanie w wielu przypadkach, w projektach w których do tej pory uczestniczyłem, był spory nacisk, żeby iść w tą stronę. Pojawiają się też projekty, w których warto zastosować podejście monorepo. Ostatni projekt, w którym aktualnie pracujemy to jest architektura mikroserwisowa, mikrofrontendowa, ale oparta o monorepo, gdzie jest 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ę często nad tym jaka przyszłość może czekać nasz projekt, kiedy podejmiemy różnego rodzaju decyzje. Sam 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'm. Hype często był mocno związany z polirepo, właśnie z podejście rozproszonym. Mamy tak naprawdę dużo plusów, dużo minusów. Dla mnie największym plusem w przypadku monorepo jest to, że mamy jedno źródło kodu, 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 mergowaniem różnych funkcjonalności, mogę wystąpić różne case'y: nie możemy wybierać chociażby różnych wersji bibliotek dla tego samego rozwiązania i raczej pracujemy w jednym języku, w jednej technologii. Ze swojej strony jak na to patrzysz?

W: 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. W tym monorepo znajduje się jeszcze jedno monorepo frontendowe, dodatkowo w związku z tym, że jedna drużyna zajmuje się najnowszą częścią naszej aplikacji, zostało to wydzielone jako polirepo. Mam całkiem niezły obraz tego jakie są plusy i minusy jednego i drugiego podejścia. 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ść to same plusy, w przeciwieństwie do tego, co oferuje polirepo. 

M: Ok. Właściwie bardziej mnie interesują minusy niż plusy. Co według Ciebie jest złego w monorepo? O plusach myślę, że jeszcze sobie porozmawiamy, natomiast te minusy są trudniejsze do znalezienia.

W: Myślę, że wiesz - zależy, ale zgadzam się z Tobą, że może są one mniej widoczne na pierwszy rzut oka. Chociaż domyślam się, że zależy z kim rozmawiasz i kogo pytasz. W naszym przypadku taka decyzja została podjęta z tego powodu, że w momencie kiedy mamy duży team i wszyscy próbujemy mergować kod do jednego brancha, powiedzmy do mastera, to zaczyna się to robić problem i trochę gubi się to wszystko w GIT'cie. Wszyskie commity, odpowiednie zarządzanie Pull Requestami jest problematyczne. Polirepo daje to, że od razu widzimy co się dzieje.

M: To się zgodzę. W zasadzie warto też tutaj podać, że w przypadku kiedy mamy 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 problem z mergowaniem kodu, można na pewno rozwiązać poprzez dobrą politykę zarządzania branchami, tworzenia branchy i zachowania odpowiedniej kolejności mergowania, ale to jest jednak dodatkowa procedura, którą trzeba sobie wdrożyć, więc zdecydowanie tak. A jakieś inne minusy?

W: To prawda. Myślę, że kolejny minus z tym trochę powiązany i to też kolejny argument dlaczego my zdecydowaliśmy się w tym nowym projekcie na podejście polirepo, to są koszty związane z CI / CD. Mianowicie za każdym razem, gdy coś jest mergowane do mastera, w momencie gdy buduje się cały projekt, który jest dość duży, pojawiają się problemy odnośnie tego, że tych commitów można robić znacznie mniej, bo master ciągle się buduje, ciągle trzeba sprawdzać i kontrolować czy można go zreleasować w każdej chwili. Jest to kolejna rzecz - czyli obciążenie naszego pipeline'u produkcyjnego czy też testowego poprzez commity, które niekoniecznie muszą być przetestowane, bo czasami mamy taki kod, kiedy budujemy jakiś nowy moduł aplikacji, gdzie na samym początku nie potrzebuje dużo testowania. Jeszcze nie dotarł do fazy MVP, a już każdy commit, który trafia do mastera jest testowany tak, jak każda inna część aplikacji. 

M: Ja widzę jeszcze dwa minusy. Pierwszy z nich to jest wersjonowanie. Wrzuciłbym to na sam początek - jest spory problem z wersjonowaniem poszczególnych części monorepo. Ten case bym ujął jako minus. Drugi case, o którym pomyślałem teraz, właśnie mi wpadł do głowy, to jest problem z ograniczeniem dostępu do poszczególnych części. Gdybyśmy np chcieli ograniczyć, że dla pewnego zespołu jest dostęp tylko do pewnej części tego repozytorium. Tutaj mógłby pojawić się problem. To może niepopularne myślenie, jeśli chodzi o ograniczanie dostępu, ale w zasadzie jakby spojrzeć na to z perspektywy bezpieczeństwa - bardzo potrzebne i bardzo konieczne. Wydaje mi się, że to jest dość istotny punkt, jeżeli mamy np wiele zespołów, które razem pracują na jednym projekcie i razem chcą osiągać coś, to w takim monorepo sama ilość developerów jest problemem, ale też brak możliwości ograniczeń dostępu do pewnych jego części też może być problematyczne.

W: Zdecydowanie się z Tobą zgadzam Mateuszu. Myślę, że to jest bardzo dobry punkt i potrafię sobie wyobrazić, że w takich miejscach jak np. bank, w którym nigdy nie miałem okazji pracować, więc to tylko z domysłów, ale domyślam się, że jest tam jakaś infrastuktura, którą nie chcielibyśmy dzielić się z każdym pracownikiem, dawać mu dostępu do każdej części aplikacji od razu, razem z jakimś drobnym kawałkiem kodu, do którego musi dorobić zmiany. 

M: To mamy minusy. A minusy polirepo?

W: Myślę, że tutaj też jest dość dużo ciekawych dyskusji, które można mieć na temat minusów polirepo. Takie na szybko, które przychodzą mi do głowy to jest dzielenie się kodem. W momencie, kiedy napiszemy jakiś drobny kawałek naszej aplikacji - szczególnie w obrębie jednego projektu - może bardzo szybko się okazać, że to, co piszemy już było napisane. I teraz pojawia się problem, jak się tym podzielić. W momencie kiedy mamy już coś napisanego i inna osoba chciałaby z tego skorzystać. Co za tym idzie - pojawia się duplikacja kodu, która w tym momencie występuje, bo jeśli tak ciężko się nim podzielić to może się okazać, że najprościej jest po prostu duplikować ten kod. Jest to chyba najgorsza opcja, żeby tę sytuację rozwiązać. Kończymy ze straszną sytuacją, gdzie musimy utrzymywać dwa różne fragmenty tego samego kodu w dwóch różnych miejscach.

M: A nie wydaje Ci się, że to jest problem bardzo związany z zaprojektowaniem samej aplikacji? Taki problem stricte architektoniczny? 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 jednak często dość porządane i często odchodzi się od wielkich monolitycznych aplikacji. Polirepo w takim ujęciu bardzo często jest dość mocno powiązane z architekturą mikroserwisową. Tyle tylko, że w przypadku architektury 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 lub te same rzeczy. Z perspektywy budowania takiej aplikacji to jest błąd po prostu architektoniczny. Tak by się wydawało. W zasadzie takie polirepo, gdzie mamy różne niezależne, samodzielne wręcz moduły / systemy / serwisy byłoby dość ciekawe. Wydaje się to dosyć dobrym pomysłem. Pomijając ten błąd, o którym wspomniałeś, nie powiedziałbym, że byłby to minus. Jak myślisz?

W: Rzeczywiście rozumiem Twój argument związany z architekturą. Zgadzam się, że można tego uniknąć, bazując na dobrej architekturze. Chociaż domyślam się, że jest to też taki problem, o który trzeba bardzo zabiegać, żeby go nie mieć i bardzo się postarać. Domyślam się, że są różne sytuacje, w których ten problem może się pojawić. Nawet jak bardzo pilnujemy, żeby nie posiadać tych duplikacji kodu.

M: Ale to samo może się wydarzyć w zwykłym monorepo. Duplikację kodu możemy zrobić w każdym miejscu. Jedynym argumentem za, który widzę w tym konkretnym minusie, jest to, że może w monorepo łatwiej to wychwycić. 

W: Tak i myślę, że zdecydowanie łatwiej sobie z tym poradzić. Już to, co istnieje dookoła naszego monorepo daje nam to, że możemy wydzielić sobie ten kawałek kodu i podzielić się nim w innych częściach naszej aplikacji.

M: Pomyślałem o jeszcze jednym minusie monorepo. O zależnościach. W przypadku polirepo, gdy mamy wydzielone niezależne 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 code base'ie. Mając wszystko w jednym code base'ie ogranicza nas tylko ścieżka do pliku. Ja np ten problem widzę w projekcie, w którym jestem - mamy dwie aplikacje, które są w jednym repo. Jedna aplikacja jest starsza od tej, którą ja aktualnie 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 jakieś shared katalogu czy jakiegoś common'a, co de facto powoduje, że jedna aplikacja, która jakoby jest niezależna, korzysta z zależności, które zostały wpisane w tą pierwszą aplikację. Wydaje mi się, że w przypadku polirepo byłoby to trudniejsze do zrobienia.

W: Jest to ciekawy argument. Myślę, że jest to kwestia architektoniczna. Błąd, który został popełniony trochę w innym miejscu. Zgadzam się z Tobą. W momencie, kiedy łatwiej dzielić się 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ć. Myślę, że jak wiesz ze swojego długiego doświadczenia, każde rozwiązanie ma swoje plusy i minusy. 

M: Oczywiście. Cały czas mówimy o tym, że gdzieś popełniono błędy. W zasadzie wydaje mi się, że akurat te błędy architektoniczne o wiele łatwiej popełnić w monorepo niż w polirepo. Te dwa o których wspomnieliśmy. To co, jeszcze te minusy polirepo?

W: Jasne. Możemy o nich pogadać. Przychodzi Ci coś jeszcze do głowy?

M: Utrzymanie. Zdecydowanie case utrzymania projektu w przypadku polirepo. Z jednej strony mówiłeś, że monorepo jest kosztowne jeśli chodzi o Continuous Integrations. Zdecydowanie zgadzam się, bo code base jest dość duży, to są często gigabyte'y danych. Zbudowanie i utrzymanie w procesie czy też przejście przez taki proces w ramach jednego pipeline'a na pewno jest kosztowne, ale z drugiej strony mamy polirepo, które oczywiście ścina ten koszt CI / CD, ale bardzo często, jak w architekturze mikroserwisowej, wymaga utrzymania wielu repozytoriów, wprowadzania zmian w wielu repozytoriach, gdy mamy jakieś złożone funkcjonalności a zmiana musi być wprowadzona w wielu modułach. Wprowadzenie takiej zmiany jest dość kosztowne i utrzymanie jest dużo trudniejsze niż zrobienie tego w monorepo. To byłaby wada polirepo.

W: Zgadzam się w 100%. Myślę, że ten koszt jest po prostu przełożony w inne miejsce. Ktoś kto zajmuje się pipeline'ami musi zarządzać też deploy'owaniem tego wszystkiego. Zdecydowanie łatwiej jest to zrobić w momencie kiedy wszystko jest w jednej bazie kodu niż w momencie, kiedy musisz ściągać 5, 10, 15 czy nawet więcej repozytoriów, budować to wszystko i dbać o to, żeby wszystko się odpowiednio zdeployowało, przetestowało itd. itd. Ok. To jakie widzisz plusy monorepo?

M: Na pewno odwrotność tego, o czym rozmawialiśmy. Czyli mniej konflitków, zdecydowanie mniej konfliktów w przypadku wytwarzania kolejnych wersji. To może być problematyczne, kiedy zakopiemy się w konfliktach i będziemy je rozwiązywać. Jeżeli będziemy mieć wspólne pliki, które zawsze są dotykane podczas merge'a, to każdy merge będzie dotykał tych plików i często będą one konfliktowały. To może być frustrujące i to jest na pewno duży plus polirepo. Wydaje mi się też, że odwrotność tego co też już powiedzieliśmy - zarządzanie bezpieczeństwem, czyli bezpieczeństwo i zarządzanie dostępem dla różnych poziomów, części aplikacji. Wydaje mi się też, że łatwiej użyć w polirepo tych DevOps Tools - zresztą o tym też wspominałeś. Ja bym tak na to patrzał. Dodatkowo zarządzanie zależnościami na pewno jest ciekawsze z perspektywy polirepo, aczkolwiek monorepo też ma swój plus tutaj - współpraca, to jest to o czym rozmawialiśmy, czyli code base jest wspólny. Z jednej strony fajnie, że w monorepo wszyscy mamy dostęp do jednej bazy kodu i razem nad tym pracujemy, dzięki czemu jest łatwiej to rozwijać, ale z drugiej strony mamy ten problem, że nie mamy separacji i czasami wchodzimy sobie w drogę. DevOps'owanie - w tym temacie to już chyba porozmawialiśmy, wydaje mi się, że zgadzamy się co do tego, że w zależności od tego na co położymy większy nacisk - czy na koszt CI/CD, wtedy jeśli chcemy żeby ten koszt był niższy - polirepo będzie fajniejszym rozwiązaniem. Jeśli chodzi o utrzymanie spójności to wydaje mi się, że monorepo będzie praktyczne. Jeszcze są dwa tematy, które powinniśmy poruszyć. Jeśli chodzi o plusy polirepo to myślę, że warto wspomnieć o rozmiarze paczek, czyli stack technologiczny możemy sobie wydzielić bardzo precyzyjnie per moduł, możemy podjąć decyzję o wersjach, które chcemy wykorzystywać w ramach poszczególnych serwisów, możemy podjąć decyzję w jakich językach chcemy pisać poszczególne fragmenty, więc z perspektywy polirepo mamy większa dowolność, większą swobodę. W zasadzie są też różnego rodzaju podejścia pozwalające nam na to samo w monorepo, np. z wykorzystaniem frameworków. A Ty co myślisz o dobieraniu stacku czy też wersji? Jak byś to rozwiązał w monorepo? Już sam nie wiem w zasadzie, czy Ty jesteś zwolennikiem czy przeciwnikiem monorepo.

W: Ja też jestem pogubiony Mateuszu, czy Ty jesteś zwolennikiem czy przeciwnikiem. Wracając jeszcze do tego dzielenia się kodu w monorepo między developerami to myślę też, że ogromnym plusem jest to, że w momencie w którym posiadamy monorepo - chcąc czy nie chcąc developerzy pracując nad jakimś wycinkiem aplikacji, poznają jej wspólne części i łatwiej można ich angażować w inne fragmenty naszej aplikacji. W momencie, kiedy mamy to podzielone na polirepo i wkładamy developera na inny projekt, powiedzmy że mamy aplikację frontendową i chcemy go przełożyć na aplikację mobilną, to wtedy jest ciężej, kiedy mamy tę architekturę polirepo niż kiedy mamy monorepo. W momencie kiedy ten nasz developer zaznajomił się już z tą bazą kodu, którą mamy, widział tam 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ć. W momencie kiedy mamy monorepo mamy praktycznie developera gotowego, bo on otwiera inny folder i zmienia trochę inne pliki.

M: Tutaj bym dodał jeszcze jedną rzecz. Tak teraz mi wpadło, że w momencie w którym mamy polirepo i mamy developera (backendowca), który potrzebuje pięciu czy sześciu serwisów u siebie lokalnie postawionych, po to żeby ten system zadziałał. Musi mieć bazę postawioną, musi mieć postawione 3 - 4 serwisy, często musi mieć postawiony jakiś frontend lokalnie, żeby móc sobie testować, ewentualnie będzie testował na jakimś Swaggerze albo Postmanie, albo czymkolwiek innym. W zasadzie 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 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. Za pomocą jednego polecenia byśmy stawiali wszystkie potrzebne serwisy, uruchamiali wszystkie niezbędne systemy. Będzie to łatwiejsze w utrzymaniu czy też w przebudowywaniu. Nie będzie trzeba pamiętać, że tu zabijam proces, tu zabijam proces, tu zabijam, tam zabijam, ten uruchamiam, bazę czyszczę, pah, jeszcze raz. Kiedy robimy to razem jest to o wiele łatwiejsze w utrzymaniu.

W: Zgadzam się z Tobą Mateuszu. Myślę też, że nawet nie idąc w rzeczy takie jak skrypty, a już myśląc o samym wersjonowaniu - domyślam się, że bardzo szybko może dojść do sytuacji, kiedy mamy dość dynamiczny projekt, w którym są robione jakiś breaking changes, w momencie w którym musimy martwić się czy to repo ma wersję 0.1, bo ta wersja 0.1 działa tylko z serwisem, który ma wersję 0.2 i tak dalej, i tak dalej. Sami musimy, w podejściu polirepo, zadbać o odpowiednie wersje. W momencie, kiedy mamy monorepo teoretycznie powinniśmy móc pobrać sobie to repozytorium i możemy sobie to deployować.

M: Zgadzam się. Odpowiadając - czy jestem zwolennikiem czy przeciwnikiem - sam nie wiem. Wydaje mi się, że oba te podejścia mają swoje plusy i minusy. 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 może być trzymany razem, a także zależy nam na spójności z jednej strony, nie mamy bardzo złożonego procesu CI / CD to wtedy monorepo jest świetnym rozwiązaniem. Sprowadza się to do tego, że każde z tych podejść jest fajne. Warto znać plusy i minusy, żeby podjąć decyzję, która będzie dobra z perspektywy nie tyle developera, ile z perspektywy projektu. Nawiążę trochę do tego o czym rozmawialiśmy ostatnio, czyli ten taki wiesz - developer experience. Przypuszczam, że w przypadku monorepo może być ciekawszy developer experience, jeśli chodzi 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 mieć fajniejszy developer experience, jeśli chodzi o wytwarzanie oprogramowania.

W: Mateuszu, czy mógłbyś powiedzieć, albo czy widzisz jakieś jasne wskazówki, guideline'y, gdzie monorepo to byłoby idealne rozwiązanie, albo to polirepo byłoby idealnym rozwiązaniem. Przychodzą Ci do głowy jakieś proste miejsca czy też zasady, którymi byś się posługiwać patrząc na projekt. Potrafiłbyś szybko stwierdzić, że to powinno być monorepo a to powinno być polirepo.

M: 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. Wydawać by się mogło, że polirepo jest trudniejsze w utworzeniu i zarządzaniu, ale w zasadzie w moim odczuciu o wiele istotniejsze i większe wymagania względem developerów stoją w momencie, gdy zdecydujemy się na monorepo. Monorepo wymaga o wiele większej samodyscypliny i samozaparcia, jeśli chodzi o rozwijanie tego projektu. 

W: Myślę, że formalizacji.

M: Formalizacji! Dokładnie. Z jednej strony ok, mamy w monorepo wszelkiego rodzaju lintery, więc te wszystkie stylelinty, eslinty, tslinty, prettiery po stronie frontedowej, które sprawią że 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 już powstała, wiedzieć gdzie szukać, bedzie wymagała dużego rozeznania pomiędzy frontendem, backendem czy też mobilkami. Często jest tak, że w tych monorepo znajdują się wszystkie projekty naraz, zarówno backend, frontend jak i mobilka. To de facto sprowadza się do tego, że ten experience, to doświadczenie programisty musi być na dość wysokim poziomie. W przypadku polirepo, ok on zna tylko swoją działkę, tym się zajmuje, np. jest tylko frontendowcem, zna tylko Reacta, więc siedzi w React'cie, siedzi w repozytorium Reactowym, nie musi wiedzieć nic więcej. W przypadku kiedy wchodzi w to głębiej i musi postawić projekt backendowy, to już często powstają schody. W przypadku polirepo 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ść. Zadałbym pytanie 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 .NET, część w Javie, a część np. w Javascript'cie - wówczas pomimo tego, że istnieją rozwiązania, które pozwalają tym zarządzać w warstwie monorepo, wydaje mi się, że ciekawsze mogłoby być wówczas polirepo. Co jeszcze? Masz jakieś jeszcze pomysły na co zwrócić uwagę?

W: Myślę, że te dwie rzeczy o których powiedziałeś jest to całkiem niezły wskaźnik. Chociaż rzeczywiście muszę przyznać dawno się nie spotkałem z taką trochę nieoczywistą decyzją, którą trzeba podjąć, jeśli chodzi o decyzje projektowe, bo naprawdę widzę dużo plusów i minusów jednego i drugiego rozwiązania. Myślę, że testy tutaj są najlepszym rozwiązaniem. Tak?

M: Zdecydowanie tak. Jeszcze jest jeden temat, który z tym wszystkim się wiąże, czyli refaktoryzacja. Jak myślisz, które podejście mono- czy polirepo będzie łatwiejsze czy też bardziej wydajne, jeśli chodzi o refaktoryzację. 

W: Jeśli chodzi o refaktoryzację - szczególnie w dużym projekcie, myślę że jednak monorepo wygrywa. Tutaj to, o czym rozmawialiśmy chwilę temu, czyli ten moment kiedy robimy jakąś zmianę i ta zmiana dotyczy wielu miejsc, znaczy dotyczy kilku części naszej aplikacji, która się składa z kilku polirepo, domyślam się, że ta refaktoryzacja jest znacznie cięższa. Właśnie w związku z tym, że musimy zrobić 1000 PRów, odpowiednie branche, pościągać sobie to wszystko, i tak dalej, i tak dalej. W monorepo moglibyśmy to zrobić wszystko w jednym projekcie, w obrębie jednego monorepo. Osoba, która by potem robiła nam review i sprawdzała ten nasz kod, który zmieniliśmy, miałaby zdecydowanie jaśniejszy obraz tych zmian, bo widziałaby je wszystkie za jednym razem. W najgorszym wypadku przy polirepo rozmawialibyśmy z każdą drużyną oddzielnie odpowiedzialną za takie polirepo. To mogłoby być naprawdę po pierwsze problematyczne i dodatkowo długie czasowo.

M: Wojtku, zgadzam się. Spoko. Natomiast jeszcze pomyślałem o jednej rzeczy. Pomyślałem sobie o tym, że mamy jeszcze czynnik ludzki w ramach projektów, zespołów projektowych. Najczęściej jest tak, że podejście fullstackowe jest popularne, można powiedzieć, że cały czas szuka się fullstacków czy też ludzi, którzy ogarniają zarówno frontend, backend, jeszcze może są devops'ami i designer'ami, ale prawda jest taka, że nikt nie jest super wymiataczem jeśli chodzi o wszystkie technologie. Można mieć jakieś rozeznanie zarówno na backendzie, jak i na frontendzie. Szersze lub węższe. W zasadzie sprowadza się to do tego, że mamy frontendowców i backendowców. Ten podział istniał, istnieje i będzie istniał - jeszcze przez długie, długie lata. Natomiast koncepcji tego jak my dzielimy nasz projekt, jeżeli mówimy o zespole, który jest stricte podzielony na backend i frontend to często jest tak, że frontend to jest jedna aplikacja, która jest wydzielona do samodzielnego repozytorium, a pozostała część - czyli backendowcy, pracują na wielu małych repozytoriach, stosując najczęściej podejście polirepo. Co de facto sprowadza się do tego, że oni mają swoją działkę i frontend swoją. Jak to wpływa na relację pomiędzy członkami zespołu? Czy też zrozumienie przez frontendowca jak działa backend, działa polirepo w ujęciu tego, że frontend jest pojedynczym repozytorium? Czy też odwrotnie? Jak backend patrzy na ten frontend? Czy coś by się zmieniło, gdyby te zespoły pracowały razem w jednym monorepo?

W: Bardzo dobre pytanie Mateuszu. Myślę, że w dzisiejszych czasach, ogólnie, coraz bardziej się ceni taki podział, już nie wertykalny, tylko horyzontalny. 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. Jeśli chodzi o ludzi, koniec końców sprowadza się to, do osób z którymi pracujesz. Jeśli ktoś jest niemiły to niezależnie od tego czy to bedzie monorepo czy polirepo, to dużo to nie zmienia. Ale mam też wrażenie, że budowanie takich sztucznych trochę ścian pomiędzy ludźmi czy team'ami może nawet podświadomie zaogniąć ten podział pomiędzy frontendem a backendem. Takim podejściem My - Oni. Poza tym myślę, że jest w tym ogromny plus dla Ciebie jako developera czy też pracownika, że w momencie kiedy np. potrzebujesz jakieś zmiany na backendzie będąc frontend developerem możesz po prostu ją zrobić. W momencie kiedy istniejesz w systemie monorepo masz do tego znacznie łatwiejszy dostęp i możesz znacznie łatwiej developować swoje umiejętności. W momencie kiedy jest to podzielone już spotykasz się z tą barierą. A Ty jakie masz zdanie na ten temat?

M: W zasadzie nie pomyślałem o tej drugiej części, o której powiedziałeś, czyli o samorozwoju. W zasadzie o nim ciągle gadam, więc przekonałeś mnie do monorepo właśnie.

W: W poprzednim odcinku byłem ambasadorem Remixa, to teraz jestem monorepo.

M: Muszę Cię ja w końcu do czegoś przekonać, bo to nie może być tak, że ciągle mnie Ty do czegoś przekonujesz. Jeśli chodzi o ten punkt, który poruszyłeś, czyli to, że rzeczywiście staramy się budować zespoły, które potrafią swoimi kompetencjami się uzupełniać, bo ja sam to obserwuję. I niejednokrotnie już się nie mówi, że to jest Frontend Developer czy Backend Developer, często się mówi Software Engineer, czym się de facto podkreśla, że niezależnie czy to jest frontend czy backend pracujemy nad jakimś fragmentem razem - jesteśmy inżynierami, którzy pracują razem nad jakimś software'm. Tutaj się zgadzam w 100%. To tak wygląda. Ale nadal dostrzegam i widzę, że w wielu projektach jest ten sztuczny podział i on jeszcze będzie według mnie. Aczkolwiek z perspektywy monorepo, fajny punkt, bardzo fajny, bardzo mi się podoba. Mam możliwość łatwiejszego dostępu do backendu i wprowadzania tam zmian, jeśli ich potrzebuje, bez konieczności bycia tym blockerem przez kogokolwiek czy cokolwiek, że nie mogę dostarczyć, bo mi backend nie dostarczył. Albo odwrotnie frontend nie może być przetestowany, bo coś tam. Takie nawet proste zmiany, nie mówimy nawet o pełnych funkcjonalnościach, ale często pojawia się: o zabrakło nam jakiegoś filtra, backend zapomniał i coś tam się wydarzyło, więc tak naprawdę z tej perspektywy o wiele łatwiej jest wprowadzić to ręcznie, samodzielnie przez developera, niezależnie frontendowca czy backendowca, który pracuje nad konkretnym rozwiązaniem. I to jest spoko. Zgadzam się w 100%.

W: Dokładnie.

M: Już kilka razy Wojtku wspominaliśmy tutaj podczas naszej rozmowy, że mamy projekty, które 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 polirepo jest to zdecydowanie łatwiejsze w utrzymaniu wówczas. Ale czy monorepo staje się niedostępne, kiedy mamy wiele różnych języków?

W: Wydaje mi się, że nie Mateuszu. Tak jak rozmawialiśmy przed naszym nagraniem, że takie firmy jak Google czy inni giganci z Silicon Valey, od zawsze mają monorepo i od zawsze też tworzą praktycznie narzędzia do zarządzania 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 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óre one nam dają. 

M: W zasadzie nie pomyślałem o tej drugiej części, o której powiedziałeś, czyli o samorozwoju. W zasadzie o nim ciągle gadam, więc przekonałeś mnie do monorepo właśnie.

W: W poprzednim odcinku byłem ambasadorem Remixa, to teraz jestem monorepo.

M: Muszę Cię ja w końcu do czegoś przekonać, bo to nie może być tak, że ciągle mnie Ty do czegoś przekonujesz. Jeśli chodzi o ten punkt, który poruszyłeś, czyli to, że rzeczywiście staramy się budować zespoły, które potrafią swoimi kompetencjami się uzupełniać, bo ja sam to obserwuję. I niejednokrotnie już się nie mówi, że to jest Frontend Developer czy Backend Developer, często się mówi Software Engineer, czym się de facto podkreśla, że niezależnie czy to jest frontend czy backend pracujemy nad jakimś fragmentem razem - jesteśmy inżynierami, którzy pracują razem nad jakimś software'm. Tutaj się zgadzam w 100%. To tak wygląda. Ale nadal dostrzegam i widzę, że w wielu projektach jest ten sztuczny podział i on jeszcze będzie według mnie. Aczkolwiek z perspektywy monorepo, fajny punkt, bardzo fajny, bardzo mi się podoba. Mam możliwość łatwiejszego dostępu do backendu i wprowadzania tam zmian, jeśli ich potrzebuje, bez konieczności bycia tym blockerem przez kogokolwiek czy cokolwiek, że nie mogę dostarczyć, bo mi backend nie dostarczył. Albo odwrotnie frontend nie może być przetestowany, bo coś tam. Takie nawet proste zmiany, nie mówimy nawet o pełnych funkcjonalnościach, ale często pojawia się: o zabrakło nam jakiegoś filtra, backend zapomniał i coś tam się wydarzyło, więc tak naprawdę z tej perspektywy o wiele łatwiej jest wprowadzić to ręcznie, samodzielnie przez developera, niezależnie frontendowca czy backendowca, który pracuje nad konkretnym rozwiązaniem. I to jest spoko. Zgadzam się w 100%.

W: Dokładnie.

M: Już kilka razy Wojtku wspominaliśmy tutaj podczas naszej rozmowy, że mamy projekty, które 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 polirepo jest to zdecydowanie łatwiejsze w utrzymaniu wówczas. Ale czy monorepo staje się niedostępne, kiedy mamy wiele różnych języków?

W: Wydaje mi się, że nie Mateuszu. Tak jak rozmawialiśmy przed naszym nagraniem, że takie firmy jak Google czy inni giganci z Silicon Valey, od zawsze mają monorepo i od zawsze też tworzą praktycznie narzędzia do zarządzania 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 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óre one nam dają. 

M: Ale jeżeli spojrzymy na to głębiej, to żeby utrzymywać w jednym monorepo wiele języków najczęściej musielibyśmy skorzystać z dodatkowego narzutu w postaci jakiegoś frameworka. Tutaj pojawiają się różne frameworki, np. Nx, który z tego co czytałem wspiera różne technologie w ramach jednego monorepo. Pytanie czy warto w ogóle? Czy warto wrzucać dodatkowy narzut technologiczny w postaci frameworka, który będzie stał nad wszystkim i który będzie tym w odpowiedni sposób zarządzał, przygotowywał nam te projekty. Miałeś do czynienia z takimi frameworkami jak Nx? Korzystałbyś w ogóle z takiego frameworka w momencie, kiedy miałbyś taki projekt: wiele różnych języków, różne technologie, różne frameworki i wszystko trzeba umieścić w monorepo. Czy raczej próbowałbyś to szyć na miarę i robić coś samodzielnego?

W: Pierwsze co mi przychodzi do głowy, właśnie w kontekście Nx'a i korzystania z różnych technologii i tego też o czym rozmawialiśmy wcześniej, czyli overheadu, którego sobie dodajemy Nx'em, że musimy go skonfigurować, na początku wydaje się to dużo pracy i pewnie tak jest. Szczególnie w momencie, kiedy jest to monorepo wielojęzykowe to fajnym jest to, że mamy to sformalizowane od razu i ta wiedza, która jest dookoła naszego projektu i deployowania go, jest zawarta w repozytorium razem z tymi konfiguracjami do Nx'a czy innego narzędzia, które wykorzystujemy do zarządzania i deployowania tego naszego monorepo, a nie jest schowane w jakiejś dokumentacji. Jest ona zrobiona w formie konfiguracji i teoretycznie to narzędzie powinno zapewniać, że klikam sobie tam start - cokolwiek, wpisuję komendę w konsolę i wszystko się buduje, i wszystko się wystawia. 

M: Ok. Jak dodajesz nowy framework to jesteś też podatny na kolejne bugi, które mogą wystąpić w samym frameworku i konkretne ograniczenia, które mogą być związane z konkretnym rozwiązaniem, konkretnym frameworkiem.

W: Zdecydowanie tak. Tutaj kończy się trochę moja wiedza, jeśli chodzi o takie monorepo wielojęzykowe. Domyślam się, że można to rozwiązywać na wiele różnych sposobów, chociażby skryptami, o których Ty wspominałeś dzisiaj, dockerami i skryptami bashowymi. Wydaje mi się, że jest to rozwiązanie. Chociaż myślę, że jest ogromny plus, tak jak z każdym narzędziem Mateuszu, wiesz jak to jest. To są znowu zawsze plusy i minusy. Rzeczywiście otwieramy się na bugi, może być też tak jak z Lerną, prawda? Która przestała być wspierana, a koniec końców została kupiona przez Nx'a, tak naprawdę przez długi czas była w dość słabym stanie. To też ryzyko, z którym musimy się mierzyć.

M: Ale była też bardzo mocno wykorzystywana jakby nie patrzeć. Dość popularna była, szczególnie do wersjonowania poszczególnych podczęści. Z tym się najczęściej spotykałem do tworzenia jakiś systemów szablonów, jakieś UI biblioteki komponentów w wewnętrznych projektach to Lerna bardzo często się tam pojawiała. 

W: Szczególnie w projektach, które musiały deployować wiele package'y, takich jak Babel powiedzmy pod względem frontendowym.Tak?

M: Tak, dokładnie.

W: Lerna rzeczywiście wtedy super się sprawdzała.

M: Mówiłeś też o Google'u. Mówiłeś, że Google czy podobne wielkie organizacje od zawsze właściwie wykorzystują monorepo i starają się dbać o to, żeby ten kod był w jednym miejscu. Sam zauważyłeś, że mniejsze firmy od niedawna zaczynają widzieć plusy tego, że monorepo też może być fajne. Nie tylko architektura mikroserwisowa. Wydaje mi się, że przyczyna może być taka, że architektura mikroserwisowa jest bardziej złożona, bardziej skomplikowana. Oczywiście trzymanie wszystkiego w jednym projekcie bez konkretnego podziału na moduły czy serwisy też jest błędem. W zasadzie architektura mikroserwisowa pojawiła się właśnie dlatego, że wszystko było trzymane w jednym miejscu i wszystko było zależnością wszystkiego. Teraz znowu mamy delikatny powrót do takiej architektury bardziej monolitycznej, ale w ujęciu, nie tyle architektonicznym co trzymania kodu w jednym repozytorium dla ułatwienia. Czy masz jakiś pomysł jaka jest przyczyna tego, że monorepo od lat jest popularne wśród gigantów branży, a wśród mniejszych firm raczej było to polirepo?

W: Myślę Mateuszu, że też chętnie poznam Twoje zdanie na 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. Myślę, że dopiero od niedawna pojawiają się takie narzędzia w środowisku javascriptowym, o którym głównie rozmawiamy, które znacznie ułatwiają tworzenie monorepo, mając na względzie środowisko Javascriptowe, które w ostatnim czasie zapewnia znacznie więcej możliwości. Do niedawna nie było to takie oczywiste, że za pomocą Javascriptu mogłeś zrobić stronę internetową, aplikację mobilną, aplikację desktopową i jeszcze tysiąc innych rzeczy. To jest mój pierwszy pomysł, dlaczego może tak być, że wcześniej potrzebowałeś po prostu doktora, który zna się konkretnie na tym narzędziu. Oczywiście trochę przesadzam, ale mam nadzieję, że rozumiesz o co mi chodzi. Druga rzecz jest taka, że po prostu inżynierowie Google i domyślam się, że cały zarząd rozważył plusy i minusy te, o których my dzisiaj rozmawialiśmy i stwierdził, że jednak podejście monorepo daje większą przewagę niż podejście polirepo. A Ty jakie masz zdanie na ten temat? Dlaczego może tak być?

M: Mi się wydaje, że największą wadą polirepo są też wady mikroserwisów. Utrudnione debuggowanie, utrudnione utrzymanie kodu, utrudnione testy integracyjne. To są takie rzeczy, które są wadami, które pojawiają się w architekturze mikroserwisowej i wydaje mi się, że monorepo jest eliminuje. Eliminuje je z tej perspektywy, że zespoły, które w dużych organizacjach nad tym pracują są dość duże i dość często się zmieniają, a zatem musi być jakiś jeden wspólny punkt zaczepienia od którego zaczynamy. I nawet jeśli mamy monorepo, i mamy architekturę rozproszoną w ramach tego monorepo, gdzie mamy podział na wiele różnych aplikacji itd. to monorepo daje większą możliwość, elastyczność rozwijania tego niż polirepo. Wydaje mi się, że właśnie dlatego te wielkie firmy wcześniej to zauważyły. W przypadku mniejszych podmiotów bardzo często te aplikacje, które są wytwarzane, to są aplikacje, które powstają szybko i szybko umierają. Giganci jak Google raczej mają te aplikacje utrzymywane przez wiele, wiele lat. Czas dostarczania czy też wytwarzania takiego oprogramowania wydaje mi się tutaj nie bez znaczenia. Im dłuższy projekt, tym biznesowo trudniejszy do utrzymania, bo pojawiają się takie tematy jak dług technologiczny, który dość mocno rośnie. Pewne serwisy, które w ramach polirepo powstały raz, po latach mogą być zapomniane i ktoś sobie przypomni: O jeju! My mieliśmy jeszcze taki serwis, a ten serwis ostatni raz był aktualizowany sześć lat temu. Cud, że jeszcze istnieje, że jeszcze funkcjonuje. W przypadku monorepo istnieje większa szansa, że ten serwis będzie rozwijany, będzie utrzymywany razem ze wszystkimi. Wydaje mi się, że mniejsze podmioty dopiero teraz zaczynają zauważać wady polirepo i starają się też, jakiś tam sposób, może zminimalizować ryzyko tego, że jak ich projekt zostanie zapomniany albo że będzie trudniejszy w utrzymaniu po prostu.

W: I też pewnie wchodzą tutaj te rzeczy, o których wspominaliśmy dzisiaj, czyli refaktoryzacja, lepsze radzenie sobie z długiem technicznym, o czym Ty pośrednio właśnie mówiłeś Mateuszu. Po prostu możliwość szybszej zmiany w wielu miejscach i łatwiejsze kontrolowanie tych zmian niż w momencie, kiedy mamy takie polirepo. 

M: Wojtek, chciałbyś jeszcze coś dodać w tym temacie? 

W: Jeśli chodzi o monorepo czy polirepo ostatnie pytanie, które przychodzi mi do głowy Mateuszu, jest takie, że właśnie w tym środowisku Javascriptowym, w którym 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, który jest 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. Wybrałbym Turborepo w porównaniu do takiego Nx'a, 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 Nx, którą zapewnie też dużo wspaniałych narzędzi i integracji, i wtyczek chociażby do samego Visual Studio Code, to jednak ta ilość konfiguracji, szczególnie na samym początku, jest naprawdę przerażająca. Nie wiem czy też słyszałeś o takim projekcie, który się nazywa PNPM.

M: Tak, o PNPMie słyszałem i to dość dużo. Nawet słyszałem w kategoriach takich, że powinniśmy już zapomnieć o tym, żeby budować nasze projekty z wykorzystaniem NPM'a, bo PNPM jest o wiele ciekawszy, szybszy i daje nam wsparcie dla wielu różnych platform, dla architektury bardziej rozproszonej, jeśli chodzi o systemy. On mi trochę przypomina Rush'a z tej strony.

W: To się z Tobą zgodzę, bo pomiędzy 2021 a 2022 rokiem jest ponad 3% zmiana jeśli chodzi o PNPM. Ilość osób, które pozostały przy PNPM'ie zwiększyła się ona z 89 do 92, a jeśli chodzi o wykorzystanie to zwiększyło się ono między rokiem 2021 a 2022 aż o 8%, jeśli dobrze liczę. Z 13 do 21%,

M: A nie sądzisz, że Turborepo to taki trochę Hype w tym momencie?

W: Nie, myślę, że nie. Myślę, że oni proponują naprawdę fajne rozwiązanie, chociaż tak jak wiemy, rynek monorepo i hype'u który jest ostatnio wokół tego tematu. Turborepo 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 Turborepo korzysta. Myślę, że to też jest ciekawe, że nawet NPM czy też Yarn zaczynają wspierać natywnie podejście monorepo. Dostarczają narzędzia, żeby łatwiej było je tworzyć. 

M: Ale z drugiej strony, z tego co wiem Turborepo zostało zaprojektowane typowo dla monorepo, ale po pewnym czasie dołożyli wparcie dla polirepo. W tym momencie Turborepo ma też wsparcie dla polirepo.

W: To ciekawostka. Nie słyszalem o tym, jeśli tak mówisz Mateuszu, to może rzeczywiście tak jest. Ale...

M: 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 spokałem się z tym, że dodali po pewnym czasie ten support, to wparcie dla polirepo również. 

W: To ciekawostka dla mnie. Nie spotkałem się z taką informacją. 

M: Dla mnie jeden wniosek. Jeden wniosek, który też to trochę podsumowuje. Zobacz narzędzie dla monorepo daje wsparcie dla polirepo. Czyli de facto, jakby na to nie spojrzeć, oba te podejścia są spoko. Tylko każde ma swoje zalety i wady, i każde ma inne zastosowanie.

W: Zgadzam się z Tobą w 100% i zastanawiam się jeszcze czy się nie myli Tobie Turborepo z Turbopack'iem?

M: Nie.

W: Ok, to jeśli Ci się nie myli to ok. I myślę, że zgadzam się odnośnie tego wniosku, podsumowania, które przedstawiłeś Mateuszu. Czy to monorepo, czy polirepo - jedno i drugie ma swoje plusy i minusy, najważniejsze jest to jak koniec końców je zastosujemy. 

M: Myślę, że to wszystko co przygotowaliśmy w dzisiejszym odcinku. Temat polirepo i monorepo jest tematem dość szerokim i otwartym. Tak jak Wojtek już zauważył, podsumowując naszą rozmowę zastosowania są różne, zależnie od tego, co chcemy osiągnąć, możemy wybrać jedno lub drugie. Jeżeli podobała się Wam nasza rozmowa, jeżeli macie jakieś komentarze, pytania lub jakikolwiek feedback, którym chcielibyście się podzielić, zapraszamy serdecznie do kontaktu z nami. Dziękujemy ślicznie za wysłuchanie dzisiejszego odcinka i jeżeli Wam się podobało to zapraszamy do subskrybowania, obserwowania, dawania łapek, komentowania i wszystkiego co tylko możliwe, żeby podzielić się z nami Waszymi odczuciami i feedbackiem. Dziękuję ślicznie, dziękujemy ślicznie. Do usłyszenia.