19 kwietnia 2018
Microserwisy na frontendzie

Jak można rozwiązać problem z organizacją aplikacji webowej, gdy monolityczne podejście jest niemożliwe? Dlaczego warto wrócić do renderowania po stronie serwera? Czy mikroserwisy na frontendzie mają jakiś sens? W tym artykule pokażę, jak można podejść do tematu rozdziału aplikacji webowych na mniejsze fragmenty.


Wstęp

Architektura mikroserwisów szturmem zdobywa pozycję w projektach związanych ze skalowalnymi rozwiązaniami webowymi. Sprawdza się ona świetnie w momencie, gdy pojedyncza platforma nie jest najlepszym narzędziem do kompleksowego rozwiązania wyzwań stawianych przez projekt. Dodatkowo możliwość pracy równolegle nad różnymi częściami rozwiązania w różnych technologiach, pozwala na szybki postęp prac.


Dynamic loading

Ciekawym sposobem organizacji architektury jest podejście oparte o dynamicznie ładowane komponenty. Często przewijającym się motywem podczas dyskusji nad rozwiązaniami tego typu są systemy zarządzania treścią. Pomysł opiera się na dołożeniu dodatkowej warstwy abstrakcji służącej do zarządzania układem komponentów na stronie. Przykładem może być “Project Mosaic”. Bazuje on na renderowaniu treści po stronie serwera – server side rendering. W pierwszej kolejności wewnętrzny mechanizm routingu, bazujący na informacjach z API decyduje o tym, które części aplikacji są potrzebne w danym momencie. Po przekazaniu tych informacji dalej do usługi zarządzającej układem, wczytuje ona i dynamicznie udostępnia komponenty.


Rysunek 1. Architektura oparta o dynamicznie ładowane komponenty.



Następnie – już po stronie klienta – za pomocą Fragments API z React oraz systemu dynamicznego ładowania modułów – require.js, uzyskujemy w pełni funkcjonalną aplikację webową.


Routing i server side rendering

W podstawowej wersji sam routing wraz z podziałem na fragmenty może okazać się wystarczający. Gdy chcemy celować w bardziej złożone rozwiazanie z głębszym podziałem bundle na części, będziemy musieli głębiej wejść w temat własnego, często specyficznego dla platformy, podejścia do server side rendering. Tutaj warto wspomnieć czym jest przejście z komponentów, rozumianych, jako statyczne pliki JavaScript i składanych w całość, jako bundle, do komponentów zdefiniowanych, jako JSON.


Listing 1. [JavaScript] Przykładowy funkcyjny komponent React

Ze względu na deklaratywną naturę reprezentacji komponentów w React nie nastręcza to większych problemów. Do przetwarzania komponentów na większą skalę warto skorzystać z bibliotek takich jak react-json-renderer.


Listing 2. [JSON] Przykładowy komponent React już po skonwertowaniu do formatu JSON

Aktualizacja fragmentów opiera się o standardową komunikację poprzez REST API z serwisem zarządzającym układami. Pozwala to na łatwy i skalowalny sposób zarządzania zmianami w poszczególnych komponentach, co umożliwia kompletne odseparowanie ich od siebie. Tworząc tego typu rozwiązania, trzeba wziąć pod uwagę szereg czynników, takich jak wymogi wydajnościowe, możliwość podziału zadań pomiędzy zespoły deweloperskie, synchronizację modułów, docelowy poziom jakości oraz pożądany zakres konfigurowalności. Podstawą, od której warto zacząć budowanie takiego systemu jest przygotowanie środowiska testowego spełniającego docelowe kryteria, jakie postawiliśmy przed rozwiązaniem. Modelowy przykład użycia na tak wczesnym etapie pozwala na uniknięcie problemów związanych ze zbyt rozmytym zakresem konfigurowalności lub zbyt wczesną optymalizacją rozwiązania.


Podsumowanie

Pomimo wielu zalet, model opisany wcześniej zakłada separację już na poziomie poszczególnych komponentów. Przekłada się to na dodatkowy nakład pracy związanej ze skalowaniem oraz kolejkowaniem komunikacji wewnętrznej, aby móc w stu procentach wykorzystać możliwości, jakie zapewnia taki podział.Dodatkowo warto rozważyć kwestie zależności współdzielonych pomiędzy komponentami oraz komunikacji pomiędzy komponentami podczas działania aplikacji.

Zostaw komentarz (0 komentarzy)

Napisz opinię…
W przypadku naruszenia Regulaminu Twój wpis zostanie usunięty.
Twoje imię i nazwisko

    Kontakt

    Transition Technologies PSC Sp. z o.o.
    Polska, Łódź 90-361, ul. Piotrkowska 276
    NIP 729-271-23-88

    tel.: +48 42 664 97 20
    fax: +48 42 664 97 30

    office@ttpsc.pl