• Home
  • Blog
  • Mikroserwisy na frontendzie. Jak zarządzać stanem aplikacji – biblioteka Eventrix

TECHNOLOGIE

17.06.2021 - Przeczytasz w 3 min.

Mikroserwisy na frontendzie. Jak zarządzać stanem aplikacji – biblioteka Eventrix

17.06.2021 - Przeczytasz w 3 min.

Jak wygląda architektura mikroserwisowa na frontendzie? To nic innego jak podział aplikacji na serwisy, które są od siebie niezależne i dają naszym modułom określone dane i zapewniają komunikację względem określonej domeny w naszej aplikacji. Zobacz jak w zarządzaniu stanem globalnym może pomóc Eventrix - biblioteka autorstwa Mariusza Przodała, w RST pełniącego rolę Technical Team Lead.

RST mikroserwisy na frontendzie

Czyli mamy wiele serwisów, a każdy jest odpowiedzialny za coś innego. Nasze moduły, czyli powiedzmy osobne strony w aplikacji, korzystają z jednego lub wielu serwisów aby móc wyświetlić określone dane w czytelnej i przejrzystej dla użytkownika formie. Wydaje się, że wszystko jest łatwe i proste, ale co w przypadku informacji, które potrzebuje trzymać w stanie globalnym, i są używane w wielu modułach lub komponentach? Taka sytuacja zmusza nas do przetrzymywania danych w stanie globalnym, który może być współdzielony pomiędzy serwisy i moduły naszej aplikacji. To właśnie taka sytuacja sprowokowała mnie do działania i stworzenia Eventrixa.

Eventrix biblioteka, która pozwoli Ci zarządzać stanem globalnym

Jeżeli potrzebujesz zarządzać stanem współdzielonym pomiędzy serwisy i komponenty w aplikacji, Eventrix jest do tego najlepszym rozwiązaniem. Dodatkowo umożliwia komunikację pomiędzy tymi elementami za pomocą eventów. Można w pewien sposób porównać jego działanie do message brokera dla frontendu tylko z dodatkiem, który umożliwia zarządzanie stanem globalnym. 

Mówiąc w skrócie, Eventrix jest przekazywany do wszystkich serwisów i modułów, dzięki czemu mogą się one ze sobą komunikować. Serwisy odpowiedzialne są za odbieranie eventów i modyfikowanie stanu, a komponenty nasłuchują na zmianę stanu aby móc się przeładować nowymi danymi oraz emitują eventy.

Cała architektura opiera się na 4 elementach:

  • state – stan globalny aplikacji który jest zarządzany za pomocą stateManager w instancji Eventrixa. StateManager emituje eventy o zmianie stanu,
  • receiver – odbiornik eventów który może modyfikować stan, ponieważ ma dostęp do stateManager po zarejestrowaniu go w instancji Eventrixa,
  • listener – nasłuchuje na eventy w instancji Eventrixa aby wykonać jakieś dalsze akcje,
  • emitter – funkcja “emit” emitująca eventy poprzez instancję Eventrixa.

Umożliwiają nam one komunikację pomiędzy serwisami i komponentami w aplikacji. Głównym założeniem jest, aby serwisy rejestrowały swoje receivery, które będą miały za zadanie pobierać dane z serwera i umieszczać je w stanie globalnym. Oczywiście aby taki receiver się wywołał, musi zostać wyemitowany jakiś event na, który on nasłuchuje. Komponenty powinny mieć za zadanie emitowanie eventów oraz nasłuchiwanie na zmianę stanu i inne emitowane eventy.

Wybierz bibliotekę która ma więcej zalet niż wad

Teraz kwestia co nam daje Eventrix, czego nie dają nam inne rozwiązania, które umożliwiają zarządzanie stanem globalnym.

Pierwszą zasadniczą różnicą jest to, że Eventrix informuje o zmianie stanu i dokładnie określa jaki stan się zmienił. Dzięki temu komponenty mogą nasłuchiwać na konkretne stany i zostaną przerenderowane tylko wtedy, gdy stan, na który nasłuchują zostanie zmodyfikowany.

Kolejnym atutem jest możliwość komunikowania się komponentów między sobą za pomocą eventów. Komponenty mogą znajdować się gdziekolwiek w strukturze aplikacji, a dzięki Eventrix mają one możliwość wysyłania eventów i słuchania na nie.

Ostatnim a zarazem bardzo ważnym aspektem jest to, że dzięki takiej, a nie innej architekturze moduły i serwisy nie są zależne od siebie w sposób bezpośredni. Serwisy i moduły nie są zależne od siebie ponieważ, nasłuchują one na eventy i je emitują. Jeżeli coś się nie załaduje, to po prostu nie będzie emitować eventów lub na nie nasłuchiwać. Stracimy pewne funkcjonalności, ale pozostałe elementy aplikacji będą działać poprawnie.

Eventrix oczywiście ma pewne wady i bolączki. Jedną z nich jest konieczność dbania o to aby nazwy eventów były w jednym miejscu i  aby była ustalona konwencja nazewnictwa tych eventów. Może być to nieco kłopotliwe, ponieważ tych eventów przy dużej aplikacji jest naprawdę bardzo dużo. Warto wtedy podzielić eventy domenowo tak, aby łatwiej można było określić ich pochodzenie, bądź grupę odbiorczą. Przy dużej aplikacji, ilość eventów może być kłopotliwa, ale można sobie z tym poradzić.

Zalety:

  • enkapsulacja funkcjonalności,
  • możliwość tworzenie niezależnych od siebie generycznych rozwiązań,
  • mała ilość kodu do napisania,
  • narzędzie developerskie wspomagające optymalizację,
  • nasłuchiwanie tylko na to co jest ważne dla komponentu,
  • komunikacja pomiędzy komponentami lub serwisami.

Wady:

  • trzeba dbać o to aby nazwy eventów były unikalne.

Jeśli chcesz zobaczyć krok po kroku, jak użyć biblioteku Eventrix wejdź tutaj.

Więcej o mikroserwisach przeczytasz w artykule Andrzeja Lewandowskiego:
Mikroserwisy – architektura oparta o mikrousługi. 

Ocena artykułu

Udostępnij

RST Software Mariusz Przodała

Mariusz Przodała

Technical Team Lead

Doświadczony Technical Team Leader, który traktuje swoją pracę jak pasję i hobby. Zapalony programista, który najbardziej lubi tworzyć innowacyjne rozwiązania i rozwiązywać skomplikowane problemy. Dzieli się swoją wiedzą i pomaga innym, kiedy tylko jest taka możliwość. Prywatnie pasjonat militariów i strzelectwa.

Nasz serwis internetowy używa plików cookies do prawidłowego działania strony. Korzystanie z serwisu bez zmiany ustawień dla plików cookies oznacza, że będą one zapisywane w pamięci urządzenia. Ustawienia te można zmieniać w przeglądarce internetowej. Więcej informacji udostępniamy w Polityce plików cookies.