Blog

Monorepo zyskuje coraz większą popularność w świecie programowania. Jest to ciekawe rozwiązanie, jednak czy zawsze będzie najlepsze? Spróbujemy dziś odpowiedzieć na to pytanie, porównując monorepo z tradycyjnym podejściem, na przykładzie systemu opartego na mikrousługach. Musimy jednak zacząć od tego, czym właściwie jest monorepo.

Czym Jest Monorepo?

Monorepo to system przechowujący kod wszystkich projektów w jednym repozytorium. Podejście to ułatwia zarządzanie kodem. Wszystkie pliki są dostępne w jednym miejscu, więc programistom łatwiej jest współpracować. Dodatkowo unikamy problemów z niezgodnościami wersji między różnymi projektami, gdyż wszystkie zależności są zawarte w jednym repozytorium.

Ponadto, w przypadku monorepo mamy możliwość ponownego wykorzystania kodu. Jest on dostępny w jednym miejscu, więc możemy łatwo odnajdywać i przenosić fragmenty kodu pomiędzy różnymi projektami. Poprawia to znacznie efektywność pracy i skraca czas potrzebny na rozwój oprogramowania.

Nie jest to jednak rozwiązanie wolne od wad. Głównym mankamentem jest czas kompilacji i budowania projektu, gdyż każda zmiana wymusza robienie tego od nowa. Te procesy mogą zajmować dużo czasu, szczególnie przy dużym repozytorium.

Zupełnie inaczej jest w systemie opartym na niezależnych od siebie mikrousługach. Tam zmiana jednej usługi nie skutkuje koniecznością ponownej kompilacji i budowania całego systemu, więc wdrażanie zmian jest dużo szybsze. Ma to znaczenie szczególnie w dynamicznych i złożonych systemach.

Minusem monorepo jest także trudność w utrzymaniu spójności kodu. Im większe repozytorium, tym łatwiej stracić kontrolę nad wprowadzanymi zmianami i ich wpływem na pozostałe części systemu. Wszystkie zmiany są przechowywane w jednym miejscu, co sprawia, że ewentualne konflikty i błędy mogą być trudne do zidentyfikowania oraz naprawienia.

W systemie opartym na mikrousługach każda usługa jest oddzielnym repozytorium, co usprawnia zarządzanie i kontrolę nad zmianami w kodzie. Każda usługa ma własną historię zmian i możliwość ich przetestowania przed wdrożeniem. Co za tym idzie, jest to rozwiązanie bardziej przejrzyste i elastyczne pod względem zarządzania projektem.

Jednak problemy są po to, żeby je rozwiązywać. Dlatego też, jako odpowiedź na powyższe wady, w środowisku JavaScript/TypeScript powstał projekt pozwalający znacząco skrócić czas budowania. Mowa o Nx.

Czym jest nx?

Nx jest jednym z najpopularniejszych narzędzi, jakie powstało, żeby wspomagać pracę z monorepo. Posiada ono wiele funkcji i ułatwień, które mają bezpośredni wpływ na zwiększenie efektywności pracy nad projektem.

Jedną z głównych przewag narzędzia Nx jest możliwość jednoczesnego wykonywania wielu zadań. Dzięki temu możemy jednocześnie kompilować, budować i testować wiele części projektu, co przyspiesza proces rozwoju oprogramowania. Różnica jest widoczna szczególnie przy większych i bardziej złożonych projektach.

Tym, co robi różnicę, są także wbudowane w Nx funkcje do zarządzania zależnościami między modułami. Przykładowo, narzędzie automatycznie wykryje zależności między modułami i pozwoli na zbudowanie wyłącznie tych części projektu, które są wymagane przy wprowadzanych zmianach. Skróci to czas kompilacji i pozwoli uniknąć budowania całego projektu.

Niestety nauka i adaptacja do nowego narzędzia może być wyzwaniem, szczególnie w przypadku większych zespołów. Konieczność poznania i dostosowania swojej pracy do narzędzia Nx wymaga czasu, chęci i dodatkowego wysiłku od programistów. Dodatkowo poziom skomplikowania i mnogość funkcji mogą przytłoczyć i zniechęcić do wprowadzania zmian.

Nie możemy zapominać także o zwiększonym zużyciu zasobów. Narzędzie musi zarządzać większą ilością modułów i zależności, co zwiększa zużycie pamięci i procesora. Spadek wydajności będzie odczuwalny w szczególności na słabszym sprzęcie. Mimo wszystko warto rozważyć wprowadzenie tego narzędzia, gdyż pomaga ono rozwiązać liczne problemy, których wiele zespołów nie było nawet świadomych.

Struktura plików i katalogów

Praca z monorepo wymaga zachowania porządku w strukturch plików i katalogów. Co prawda jest to istotne w każdym projekcie, ale tutaj trzeba się szczególnie zastanowić, czy wrzucamy kod do katalogów współdzielonych, czy do konkretnej usługi. Będzie to miało duży wpływ na naszą dalszą pracę.

Przy pomocy narzędzia Nx, struktura katalogów w monorepo zazwyczaj opiera się na logicznym podziale projektu na moduły lub paczki. W tej sytuacji każdy moduł lub paczka jest niezależną częścią systemu, która może być kompilowana, testowana i rozwijana niezależnie od innych modułów.

Oto przykładowa struktura katalogów w monorepo:

• apps: Katalog zawierający wszystkie aplikacje będące częścią systemu. Każda aplikacja może mieć swoje własne zależności, konfiguracje i testy.
• libs: W tym katalogu przechowywany jest współdzielony kod używany przez różne aplikacje w systemie. Może to być np. biblioteka komponentów UI, narzędzia pomocnicze, czy integracje z zewnętrznymi usługami.
• tools: Katalog z narzędziami pomocniczymi, skryptami i konfiguracjami używanymi do budowania, testowania i wdrażania systemu.
• e2e: Katalog z testami end-to-end, sprawdzającymi funkcjonalność całego systemu. Testy te mogą być uruchamiane na różnych aplikacjach jednocześnie, do sprawdzania integracji między nimi.
• jest: W tym katalogu znajdują się testy jednostkowe napisane przy użyciu frameworka Jest, które są uruchamiane niezależnie dla poszczególnych modułów i pozwalają na sprawdzenie poprawności działania poszczególnych części systemu.
• tslint.json: Plik konfiguracyjny dla narzędzia TSLint, służącego do statycznej analizy kodu i wykrywającego potencjalne błędy lub niezgodności z przyjętymi standardami.
• tsconfig.json: Plik konfiguracyjny.

Narzędzie Nx umożliwia automatyczne generowanie struktury katalogów w monorepo, co znacząco ułatwia proces tworzenia i zarządzania projektem. Z tego rozwiązania korzystają m.in. tacy giganci jak T-Mobile, czy Fedex, czyli firmy budujące duże i skalowalne systemy. Nie oznacza to jednak, że wszystkie globalne korporacje zdecydowały się na ten krok. Nie korzystają z niego np. Netflix czy Amazon.

Wybór stosu technologicznego zależy od indywidualnych potrzeb i strategii danej firmy. Bez względu na to, czy korzysta ona z Nx, czy też innego rozwiązania, najważniejsze jest posiadanie systemu, który najlepiej wpisuje się w jej wymagania, co pomoże w utrzymaniu niezawodności, efektywności i realizacji celów biznesowych.

Czy w moim projekcie sprawdzi się monorepo?

Osobiście uważam, że problemy z korzystania z multirepo, (takie jak duplikacja kodu) nie powinny być wystarczającą przesłanką do przechodzenia na monorepo w małych projektach.

Bardzo łatwo możemy doprowadzić do silnych zależności i okaże się, że zamiast monorepo wracamy do architektury monolitycznej. Warto przetestować możliwości i ograniczenia monorepo przed wdrożeniem komercyjnym. Możemy to zrobić na jakimś znanym przykładzie, np. sklepu internetowego.

Na początek do zaplanowania architektury wszystkich niezbędnych serwisów w podejściu multirepo wystarczy nam kartka i długopis. Dopiero w kolejnym kroku spróbujmy przenieść to do monorepo z pomoc narzędzi, choćby takich jak wspomniany w tym artykule Nx.