Front end do niedawna: jeden zespół, wspólny kod
Tworzenie aplikacji webowych z czasem staje się uciążliwe. Obrastają one bowiem w kolejne funkcje i elementy, przez co coraz trudniej nimi zarządzać.
Niezależnie od rozmiaru większość współczesnych aplikacji internetowych opiera się na:
- Wspólnym kodzie;
- Jednym zespole programistów.
Rozbudowana strona przerasta możliwości jednego zespołu
Dopóki strona jest mała, jeden zespół i wspólny kod są wystarczające. Wszyscy programiści zaangażowani w projekt posiadają o nim taką samą wiedzę, więc praca i komunikacja postępuje bez przeszkód. Ale z czasem ilość kodu zwiększa się, aplikacja staje się bardziej złożona i konieczne jest poszerzenie zespołu o kolejnych programistów.
Wcześniej czy później projekt okazuje się zbyt duży, żeby mógł go ogarnąć w całości pojedynczy człowiek. Wtedy w zespole powstają „silosy wiedzy”. Rozbijają one komunikację i pogarszają wyniki. „Od pewnego momentu” – pisze Frederick Brooks w „The Mythical Man-Month” – “dodawanie kolejnych członków do zespołu przestaje zwiększać produktywność.”
„Od pewnego momentu dodawanie kolejnych członków do zespołu przestaje zwiększać produktywność.”
Frederick Brooks, „The Mythical Man-Month”
Back end zdążył się przystosować, front end (jeszcze) nie
Początkowo wszelkie aplikacje – nie tylko webowe – były od początku do końca rozwijane jako monolity, bez podziału na front i back. Mogły więc rozrastać się bez końca, zmieniając się w olbrzymy. Żeby ułatwić sobie życie, twórcy oprogramowania rozbili te olbrzymy na dwie części – front end i back end. W ten sposób łatwiej było je okiełznać. Po jakimś czasie tak samo potraktowano sam back end: został podzielony na mniejsze części zwane mikroserwisami. Łączyła je w jeden system tak zwana warstwa agregacji.
Niestety przez cały czas front end pozostawał w miejscu. Dziś często nadal jest nieporęcznym potworkiem, który „spoczywa” na ramionach mikroserwisów. (Rys. 1)
Rys. 1.: Ewolucja architektury back-endowej na tle stagnacji front endu
Problem w tym, że dzisiejszy front end dzielą od wczorajszego lata świetlne. Obecnie za pomocą samego HTML5 da się zrobić pełnoprawne gry wideo, zaś CSS pozwala na tworzenie imponujących animacji. Nie ma więc sensu pozostawać przy tej samej metodologii rozwijania oprogramowania, która obowiązywała w latach dwutysięcznych.
Micro frontend wprowadza pionowy podział zespołów: ważniejszy od technologii staje się interes klienta
Podejście micro frontendowe przejawia się na dwa sposoby. Pierwszy dotyczy człowieka, drugi technologii. W przypadku ludzi chodzi o to, w jaki sposób podzielimy ich na zespoły. Tradycyjnie we front endzie zasadą organizującą przydział do zespołów jest konkretna technologia – np. React, JavaScript, itp. W micro front endzie główną racją bytu zespołu jest wartość dla klienta, niezależnie od technologii.
Struktura zespołu odzwierciedla główne cechy architektury micro frontendowej
Struktura micro frontendu jest podobna do tej mikroserwisowej w back endzie. Rysunek 2. przedstawia widok z lotu ptaka na architekturę micro frontendową. Da się zauważyć wizualne podobieństwa do mikroserwisów z rysunku 1.: kilka pionowych filarów zespolonych u góry warstwą integracji.
Oto lista najważniejszych cech podejścia micro frontendowego, ukazanych przez pryzmat organizacji zespołów:
- Zespoły dzielimy według wartości, którą mają dostarczyć klientowi, nie według technologii;
- Są one interdyscyplinarne i wielozadaniowe – łączą ekspertów z różnych dziedzin, np. programistów, projektantów UX, itp.;
- Konkretna, udokumentowana misja określa, nad jaką częścią strony pracuje dany zespół;
- Zakres prac zespołu może być dowolny, o ile znajduje uzasadnienie w misji. Jeden zespół może np. zajmować się fragmentem kodu, inny określoną sekcją strony, jeszcze inny całym serwisem, etc.;
- Wybór technologii w zespole jest również dowolny – najważniejsze jest osiągnięcie założonego rezultatu;
- Zespoły pracują osobno, ale porozumiewają się odnośnie kwestii, które mają wpływ na ostateczny rezultat, takich jak wydajność strony albo szata graficzna;
- Wynik pracy każdego zespołu łączy w jedno warstwa integracji, która działa po stronie serwera albo klienta;
Rys. 2.: Schematyczny rzut na całe podejście micro frontendowe
Zespołom przyświecają specjalne misje, które dotyczą potrzeb konsumenta
Czym jest misja? To dokument, który definiuje, jakie potrzeby konsumenckie chcemy spełnić lub jakie przypadki użycia nas interesują. Spójrzmy na przykład na Rys. 3. Kiedy klient czegoś szuka, zespół „Inspire” pomaga mu to znaleźć. Gdy opcje wyboru się już zawężą, zespół „Decide” ułatwia podjęcie decyzji. I wreszcie, kiedy klient wie już, czego chce, zespół „Checkout” przeprowadza przez proces zakupu.
Rys. 3.: Zespoły i ich misje
Zadaniem zespołów jest przeprowadzić klienta przez lejek sprzedażowy
Pewnie zauważyliście, że powyższe misje odpowiadają mniej więcej etapom podróży klienta lub lejka sprzedażowego. Lejek sprzedażowy dzielony jest na różne sposoby, ale w najbardziej podstawowej wersji może wyglądać tak, jak na Rys. 4. Widzimy tu następujące etapy:
- Świadomość (awareness) – klient musi wiedzieć, że dana opcja istnieje;
- Rozważanie (consideration) – klient ocenia dostępne opcje;
- Zakup (checkout) – klient decyduje się na transakcję.
Rys. 4.: Lejek sprzedażowy
Lejek sprzedażowy (podróż klienta) określa podział pracy w podejściu micro frontendowym
W web designie lejek sprzedażowy (często traktowany równoznacznie z „podróżą klienta”) często pokrywa się z elementami/funkcjami aplikacji webowej.
Na przykład: klient dowiaduje się, że dana opcja istnieje, odwiedzając naszą stronę (zyskuje świadomość); następnie przegląda dostępne produkty lub usługi (rozważa dostępne możliwości). I wreszcie podejmuje decyzję o zakupie poprzez umieszczenie wybranych elementów w koszyku i przejście do płatności.
Zespoły micro frontendowe, elementy oraz funkcje strony, a także etapy podróży klienta możemy połączyć w jedno – jak na Rys. 5:
Rys. 5.: Zespoły oraz elementy strony
Jeden zespół pracuje nad powtarzającymi się elementami na stronie
Związek między elementami oraz funkcjami strony a etapami podróży klienta nie zawsze jest jednoznaczny. Na przykład nagłówek albo stopka mogą powtarzać się na każdej podstronie. Angażowanie do pracy nad takim elementem wszystkich zespołów naraz byłoby mało produktywne, więc w micro frontendzie deleguje się do tego tylko jeden zespół. Te powtarzające się elementy nazywamy „wyizolowanymi interfejsami użytkownika” (Rys. 6).
Rys. 6.: Tylko jeden zespół jest odpowiedzialny za wyizolowane interfejsy użytkownika – tzn. powtarzające się elementy na stronie
Większa produktywność, skuteczniejsze rozwiązywanie problemów i komunikacja dzięki wielofunkcyjności zespołów
Interdyscyplinarność zespołów micro frontendowych to istotna cecha, która odróżnia to podejście od mikroserwisów w back endzie. W przypadku mikroserwisów mamy do czynienia z zespołami zorganizowanymi wokół konkretnej umiejętności lub technologii. Członkowie zespołów micro frontendowych są natomiast dobierani pod kątem konkretnego przypadku użycia bądź potrzeby klienta (Rys. 7).
Rys. 7.: Zespoły wyspecjalizowane (po lewej) kontra interdyscyplinarne (po prawej).
Zespoły interdyscyplinarne mają następujące zalety:
- Różne punkty widzenia ekspertów sprawiają, że łatwiej jest generować nowe pomysły i skuteczne rozwiązania;
- Komunikacja między ekspertami jest lepsza, bo nie są od siebie odseparowani w „silosach wiedzy”;
- Wszyscy członkowie zespołu są bezpośrednio zaangażowani i zmotywowani;
- Potrzeby klienta wysuwają się na pierwszy plan.
Spójność produktu zapewnia kontrolowana komunikacja między zespołami
Zespoły micro frontendowe pracują oddzielnie nad różnymi elementami strony, stosując takie technologie jakie najbardziej im odpowiadają, ale przecież produkt końcowy musi wyglądać spójnie. Gdyby między zespołami w ogóle nie zachodziła komunikacja, aplikacja webowa, nad którą pracują, mogłaby ostatecznie wyglądać jak potwór Frankensteina.
Żeby zapewnić spójność produktu końcowego, komunikacja między zespołami musi być dozwolona w dwóch krytycznych obszarach:
- Wydajności strony, żeby strona działała i ładowała się odpowiednio szybko;
- Szaty graficznej, żeby strona prezentowała się spójnie.
Szybszy rozwój funkcjonalności dzięki mniejszym i lepiej ukierunkowanym zespołom
Zespoły micro frontendowe są zwykle mniejsze i bardziej skupione na potrzebach konsumenta niż tradycyjne zespoły webdevowe. Dzięki temu nowe funkcje mogą powstawać szybciej, sprawniej, i w sposób bardziej zorientowany na konsumenta niż w starym modelu.
Większa odporność na ryzyko dzięki odseparowaniu zespołów
W tradycyjnym webdevie jeden błąd może wywołać efekt domina i pociągnąć za sobą konsekwencje dla całego projektu, bo cały kod istnieje w jednym miejscu. W micro frontendzie ryzyko awarii jest ograniczone do obszaru działania jednego zespołu.
Łatwiejszy refactoring dzięki rozdzieleniu kodu
Im więcej kodu w aplikacji, tym trudniejszy refactoring. Na przykład GitHub musiał poświęcić lata, żeby pozbyć się zależności od jQuery. W przypadku micro frontendu każdy zespół pracuje na osobnym kodzie, o wiele mniejszym niż w scalonym, finalnym produkcie. Z tego powodu refactoring w micro frontendzie jest łatwiejszy, mniej kosztowny i mniej czasochłonny, a ponadto można go wykonywać etapami.
Micro frontend pozwala unowocześnić stare systemy
Za pomocą micro frontendu można przekształcić gigantyczne strony internetowe w piękne i nowoczesne aplikacje zorientowane na klienta. W rezultacie te powolne i toporne giganty mogą skorzystać ze wszystkich zalet architektury micro frontendowej, które wymieniliśmy: pionowej struktury, nakierowania na klienta, zoptymalizowania pod kątem lejka sprzedażowego, zwiększonej kreatywności, skuteczniejszego rozwiązywania problemów, efektywniejszej komunikacji, szybszego rozwoju nowych funkcji, większej odporności na ryzyko, i wreszcie: łatwiejszego refactoringu.
Micro frontend w Clurgo
Dla jednego z naszych klientów, platformy SaaS obsługującej siłownie, stosujemy podejście podobne do micro frontendu. Zespoły są podzielone na podzespoły, z których każdy odpowiada za konkretną funkcjonalność, zwaną „sub-apką”. Każda z takich sub-appek może na przykład obsługiwać zarządzanie pracownikami, booking, analitykę, itp. Na końcu wszystkie one są dynamicznie integrowane w produkt końcowy za pomocą skryptów JS.
Już wkrótce więcej technicznych szczegółów
Następnym razem przyjrzymy się technicznym szczegółom micro frontendu. Jesteście ciekawi, w jaki sposób warstwa agregacji łączy w jedno różne technologie wykorzystywane w projekcie? Zajrzyjcie tutaj niedługo, żeby się tego dowiedzieć.
