Mikroserwisy i Frontend?

microserwisyFrontend

Niedawno miałam okazję uczestniczyć w webinarze organizowanym przez GFT Polska, podczas którego Norbert Blandzi, Senior Software Engineer, opowiadał o mikroserwisach stosowanych na froncie. Postanowiłam trochę przybliżyć Wam to podejście i udało mi się zadać Norbertowi kilka nurtujących mnie pytań.

Olga: Norbert, niedawno przeprowadziłeś webinar na temat mikroserwisów na frontendzie. Powiedz mi, na jakiej podstawie stwierdzić czy w naszym projekcie warto zastosować takie rozwiązanie?

Norbert: Na początku warto zaznaczyć, że wdrożenie architektury mikroserwisów na frontendzie jest zdecydowanie łatwiejsze w początkowej fazie projektu. Jeśli aplikację, którą tworzymy, planujemy rozwijać przez dłuższy czas, a nie tylko zrobić i o niej zapomnieć to jest to już podstawa do tego, żeby pomyśleć o takim rozwiązaniu. Innym ważnym aspektem, który należy wziąć pod uwagę to wielkość naszego zespołu. Jeżeli zespół, który będzie pracował nad aplikacją, jest większy niż 5 programistów, to także może to być sygnał, aby skorzystać z dobrodziejstw, jakie dają nam frontend mikroserwisy. Z własnego doświadczenia mogę powiedzieć, że wkład na początku projektu jest tak mały, że warto je dodać, nawet, gdy nie jesteśmy pewni czy się nam przydadzą. Strat z tego tytułu nie poniesiemy, a zysk może być ogromny.

O: Podczas webinaru wspomniałeś, że w pracy wraz z zespołem zdecydowaliście na korzystanie ze Single-spa. Co było główną determinantą, która zdecydowała o właśnie takim podejściu?

N: W poprzednim projekcie z zespołem korzystaliśmy z własnej implementacji frontend mikroserwisów, z którą było kilka problemów takich jak:

  • wiele wersji tej samej biblioteki ładujących się z losową kolejnością i nadpisujących się,
  • style z jednej aplikacji nadpisywały drugą,
  • brak prostego sposobu na dodanie kolejnej aplikacji utworzonej w innym frameworku,
  • problemy z routingiem,
  • brak lazy loading.

Biorąc pod uwagę wszystkie te problemy i kilka innych, zacząłem przeszukiwać Internet w celu znalezienia najlepszego rozwiązania dla naszych potrzeb. Na początku zaczęliśmy tworzyć całość w oparciu o iframe, które można było łatwo wdrożyć. Niestety szybko okazało się, że ich stylowanie jest bardzo trudne i niewygodne, a z dostępnością dla ludzi korzystających z czytników ekranowych jest jeszcze gorzej. Ucząc się na tych błędach, zacząłem szukać dalej i trafiłem na single-spa. W Internecie nie ma dużo przykładów implementacji mikroserwisów na frontendzie. Można znaleźć dużo teorii, ale mało, kto podaje gotowe rozwiązania lub dzieli się swoimi doświadczeniami. Single-spa zaskoczyło mnie przyjazną dokumentacją z gotowymi przykładami implementacji, które łatwo mogłem przetestować w moim środowisku. Po dwóch dniach testowania uznałem, że single-spa spełnia wszystkie moje wymagania i tak zaczęła się nasza wspólna przygoda.

O: Mikrofrontend pozwala nam łączyć kilka aplikacji napisanych nawet w różnych frameworkach. Czy nie uważasz, że takie podejście może stać się problematyczne jeśli chodzi o utrzymanie projektu?

N: Jeśli chodzi o jakieś własne rozwiązania może i byłoby to problemem, ale single-spa daje nam gotowe moduły npm dla większości popularnych obecnie frameworków, co niesamowicie ułatwia tworzenie całej aplikacji. Chciałbym tutaj nadmienić, że nie jestem fanem tworzenia aplikacji z wykorzystaniem 5 różnych frameworków. Dla mnie najważniejsza jest możliwość wyboru, co ma znaczenie przy projektach trwających np. przez kilka lat. W naszej obecnej aplikacji mamy około 8 aplikacji działających razem i wszystkie są napisane z wykorzystaniem React, ale nic nie stoi na przeszkodzie, żeby za jakiś czas, gdy pojawi się nowy, super szybki framework, z niego nie skorzystać. Frameworki są tylko narzędziem, najważniejsza natomiast dla nas jest możliwość podzielenia aplikacji funkcjonalnie i przydzielenia tych części zespołom. Dzięki temu w łatwy sposób możemy utworzyć jeden zespół odpowiedzialny za rejestracje, kolejny za czat z użytkownikiem, a jeszcze inny za panel admina. W ten sposób podzielone aplikacje są zdecydowanie mniejsze i łatwiejsze w utrzymaniu.

O: Jakie było największe wyzwanie podczas wdrażania mikroserwisów na frontendów u Ciebie w projekcie?

N: Największym wyzwaniem było umożliwienie łatwego testowania aplikacji na dwa sposoby. Pierwszy – uruchamiając ją, jako samodzielną podczas prac programistycznych, gdy potrzebujemy np. dodać nowy przycisk. Drugi – uruchamiając naszą świeżo zmienioną aplikację w całym ekosystemie, razem z innymi aplikacjami. Problemem było tutaj np. uwierzytelnianie użytkownika, które dzieje się dla wszystkich aplikacji w „aplikacji kontenerze”, a gdy odpalamy aplikację samodzielnie, nie posiadamy np. tokena, aby wykonać żądania do części serwerowej. Tak samo główna paczka ze stylami znajduje się w jednym miejscu i nie ma do niej bezpośrednio dostępu, gdy aplikacja jest uruchomiona samodzielnie. Na szczęście większość tych problemów udało się rozwiązać przez wykorzystanie proxy do naszych środowisk deweloperskich, z których są pobierane wszystkie brakujące zależności.

O: Dostępność w sieci jest niezwykle ważnym zagadnieniem, niestety zdarza się, że jest ono pomijane. W kontekście mikroserwisów na co trzeba zwrócić szczególną uwagę?

N: Tak jak wspomniałem wcześniej, rozwiązanie z wykorzystaniem iframe, od razu odpada, ponieważ nie jesteśmy w stanie zrobić strony, która będzie dostępna w tym podejściu. Natomiast rozwiązanie oparte o single-spa niczym się nie różni, jeśli chodzi o dostępność od aplikacji monolitycznej. Nasza aplikacja bankowa złożona z 8 różnych aplikacji ostatnio przeszła audyt dostępności, w 100%, więc nie ma z tym najmniejszych problemów. Chciałbym tutaj wspomnieć o jednym z problemów, na który napotkaliśmy. Id elementów DOM muszą być unikatowe nie tylko dla danej aplikacji, ale i gdy są one wszystkie wyświetlone razem. My rozwiązaliśmy ten problem poprzez dodanie nazwy aplikacji przed każdym id np. gft-chat-header, gft-admin-header, gft-news-header.

O: Część osób jest sceptyczna do takiego podejścia, podaj mi 3 największe korzyści, które dają nam mikroserwisy w webdevie.

N: Moim zdaniem trzy główne korzyści to:

  • podział aplikacji na funkcjonalne części, które mogą być rozwijane niezależnie przez różne zespoły,
  • mniejsze aplikacje, to mniej zależności oraz łatwiejsze tworzenie testów, co pozwala nam na wykonanie aplikacji z mniejszą liczbą błędów,
  • dowolność wyboru, która daje nam możliwość korzystania z najlepszych narzędzi obecnie dostępnych dla naszych potrzeb bez narzekania, że gdybym zaczął projekt z frameworkiem Y, to teraz byłoby łatwiej, a tak muszę wszystko robić z starym framworkiem X.

O: Dzięki wielkie za podzielenie się swoim doświadczeniem! Fajnie było poznać Twój punkt widzenia oraz podejście do pracy z dużymi aplikacjami. Jeśli jesteście ciekawi tego zagadnienia, to polecam obejrzeć webinar, w którym Norbert, podczas sesji life coding, wdraża trzy metody korzystania z mikroserwisów na frontendzie. Odpal nagranie oraz edytor i do dzieła. 😉

A co ty myślisz o mikroserwisach? Używasz ich w swoim projektcie? Jakie masz obawy jeśli chodzi o takie podejście?

3 odpowiedzi do “Mikroserwisy i Frontend?”

  1. Zawsze, gdy czytam o mikrofrontendach, to przypomina mi się prelekcja Zakasa z okolic 2010 o skalowalnej architekturze frontendowej (https://www.slideshare.net/nzakas/scalable-javascript-application-architecture ). Podstawowym założeniem było „wszystko jest modułem”. I rzeczywiście, każdy element aplikacji był niezależnym modułem, który komunikował się wyłącznie z core’em systemu, orkiestrującym działanie wszystkich pozostałych modułów. Główna różnica między tym rozwiązaniem, a mikrofrontendami, to fakt, że istniał tam wspólny stack, na którym wszystkie moduły były oparte. I niekoniecznie jest to wada – zwłaszcza, jeśli do równania dołożymy wydajność.

    Pomysł na mikrofrontendy nie jest nowy, to jest po prostu rozbudowanie podziału na moduły do ekstremum. Z tym, że IMO większość korzyści z korzystania z mikrofrontendów da się też osiągnąć przy pomocy dobrej architektury modularnej, np. nie ma przeszkód, by oddzielne zespoły pracowały nad osobnymi modułami. Dodatkową korzyścią jest właśnie wspólny stack, który minimalizuje problemy z wydajnością.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.