Czym jest usługa Service Bus i dlaczego Microsoft stawia na komunikaty w chmurze?

Azure Service Bus pozwala oddzielić producentów komunikatów od ich konsumentów. Dzięki temu aplikacje nie muszą znać się nawzajem ani działać w tym samym czasie. Komunikaty mogą być bezpiecznie przechowywane, ponawiane i przetwarzane asynchronicznie, co znacząco poprawia stabilność całego systemu.

Z perspektywy architekta jest to jedno z kluczowych narzędzi do budowy systemów odpornych na przeciążenia i chwilowe awarie.

Azure Service Bus to zarządzana usługa message brokera, oferująca:

• kolejki (Queues),
• tematy i subskrypcje (Topics & Subscriptions),
• transakcje,
• obsługę kolejki utraconych wiadomości (dead-letter queue),

Nowoczesne systemy IT konsekwentnie promują komunikację asynchroniczną za pomocą kolejek z kilku powodów:

• zwiększa skalowalność,
• upraszcza rozwój mikroserwisów,
• pozwala niezależnie wdrażać i rozwijać komponenty niezależnie od użytych technologii do ich wytworzenia,
• pozwala lepiej wykorzystać zasoby chmurowe dostępne np. w środowisku Microsoft Azure.

Kolejki, Topics i subskrypcje oraz sesje – jak działa usługa Azure Service Bus?

Service Bus Queue – kolejki usługi service bus

Kolejki w Azure Service Bus realizują model point-to-point, w którym każdy komunikat trafia do kolejki i jest przetwarzany przez jednego konsumenta. Nadawca i odbiorca są od siebie niezależni – komunikaty mogą być wysyłane i odbierane w różnym czasie, co zwiększa odporność systemu na awarie i chwilowe przeciążenia.

Usługa wykorzystuje mechanizm Peek-Lock, który tymczasowo blokuje komunikat po jego odebraniu. Dopiero po poprawnym przetworzeniu jest on usuwany z kolejki. W przypadku wystąpienia błędu może zostać ponownie udostępniony innemu odbiorcy lub trafić do dead-letter queue, co ułatwia diagnostykę problemów. Mechanizm Peek-Lock pozwala konsumentowi tymczasowo zablokować komunikat w kolejce. W przypadku wygaśnięcia blokady (np. z powodu timeoutu), komunikat staje się dostępny dla innych konsumentów, co może prowadzić do powtórnego odbioru.

Jedna kolejka może być obsługiwana przez wiele instancji konsumentów. Azure Service Bus automatycznie rozdziela komunikaty pomiędzy nich, zapewniając naturalny load balancing bez dodatkowej logiki po stronie aplikacji.

Kolejki sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• przetwarzanie zadań w tle,
• kolejkowanie żądań i ochrona systemów przed przeciążeniem,
• równoważenie obciążenia pomiędzy wieloma instancjami usług,
• asynchroniczna integracja systemów.

Topics i subskrypcje

Topics w Azure Service Bus realizują wzorzec publish/subscribe, w którym jeden komunikat może zostać dostarczony do wielu niezależnych odbiorców. Producent wysyła komunikat do tematu (Topic), nie wiedząc, kto i ile systemów będzie go konsumować. Każda subskrypcja działa jak osobna kolejka, posiadająca własny stan, retry oraz dead-letter queue.

Największą zaletą Topics są subskrypcje z filtrami, które pozwalają określić, jakie komunikaty trafią do danego odbiorcy. Filtry SQL lub reguły oparte o właściwości komunikatu umożliwiają precyzyjne routowanie zdarzeń bez dodatkowej logiki po stronie producenta.

Każda subskrypcja może być obsługiwana przez wiele instancji konsumentów, co, podobnie jak w przypadku kolejek, umożliwia równoległe przetwarzanie i load balancing. Jednocześnie różne subskrypcje mogą przetwarzać ten sam komunikat w zupełnie inny sposób lub w innym tempie.

Topics i subskrypcje sprawdzają się szczególnie dobrze w scenariuszach takich jak:

• architektura event-driven,
• propagacja zdarzeń domenowych,
• integracja wielu systemów reagujących na te same zdarzenia,
• oddzielenie logiki biznesowej od procesów pomocniczych (np. powiadomień, audytu, raportowania).

Dzięki modelowi publish/subscribe Azure Service Bus Topics umożliwiają budowę elastycznych i łatwo rozszerzalnych systemów, w których dodanie nowego odbiorcy nie wymaga zmian po stronie nadawcy.

Sesje

Sesje w Azure Service Bus to mechanizm umożliwiający grupowanie powiązanych komunikatów i przetwarzanie ich w ściśle określonej kolejności. Każdy komunikat posiada SessionId, a wszystkie komunikaty z tym samym identyfikatorem trafiają do tej samej sesji i są obsługiwane sekwencyjnie przez jednego konsumenta.

W praktyce oznacza to, że choć kolejka lub subskrypcja może być przetwarzana równolegle przez wiele instancji odbiorców, to w ramach jednej sesji nigdy nie dochodzi do przetwarzania równoległego. Azure Service Bus blokuje sesję na czas jej obsługi przez konkretnego konsumenta, co eliminuje problemy z kolejnością i współbieżnością.

Sesje są szczególnie przydatne w scenariuszach, gdzie:

• kolejność komunikatów ma znaczenie (np. workflow, procesy krok po kroku),
• komunikaty dotyczą jednego obiektu biznesowego (np. OrderId),
• wymagane jest przetwarzanie stanowe (stateful processing),
• system musi zachować spójność bez skomplikowanej synchronizacji.

Sesje mogą być używane zarówno w Queue, jak i w subskrypcjach Topiców. Dzięki nim Azure Service Bus łączy wysoką skalowalność z kontrolą kolejności, co jest trudne do osiągnięcia w klasycznych systemach kolejkowych bez dodatkowej logiki po stronie aplikacji.

Azure Service Bus Queue vs Topic – kiedy wybrać które rozwiązanie?

Wybór pomiędzy Queue a Topic w Azure Service Bus zależy przede wszystkim od tego, ile systemów ma przetwarzać dany komunikat i w jaki sposób ma on być obsłużony.

Queue najlepiej sprawdzi się w scenariuszach typu point-to-point, gdzie komunikat ma zostać przetworzony dokładnie raz przez jeden komponent. Jest to idealne rozwiązanie dla zadań w tle, kolejkowania żądań czy równoważenia obciążenia pomiędzy wieloma instancjami tej samej usługi. Queue upraszcza architekturę i minimalizuje liczbę zależności pomiędzy komponentami.

Topic warto wybrać wtedy, gdy komunikat reprezentuje zdarzenie, na które powinno zareagować wiele niezależnych systemów. Dzięki subskrypcjom i filtrom możliwe jest selektywne dostarczanie komunikatów do różnych odbiorców bez modyfikowania producenta. Topic naturalnie wspiera architekturę event-driven i ułatwia dalszą rozbudowę systemu.

W praktyce często stosuje się oba mechanizmy jednocześnie:

• Queue do obsługi zadań i procesów technicznych,
• Topic do publikowania zdarzeń domenowych.

Dobrze dobrany model komunikacji upraszcza architekturę i pozwala skalować system bez kosztownych refaktoryzacji w przyszłości.

Azure Service Bus Patterns – wzorce, które warto znać

Azure Service Bus Request-Response pattern

Request–Response Pattern w Azure Service Bus umożliwia realizację komunikacji dwukierunkowej w sposób asynchroniczny, bez konieczności bezpośredniego połączenia pomiędzy nadawcą a odbiorcą. Zamiast klasycznego wywołania synchronicznego (np. HTTP), klient wysyła komunikat z żądaniem do kolejki lub tematu, a odpowiedź otrzymuje jako osobny komunikat.

W praktyce klient wysyła żądanie do Request Queue, dołączając informacje pozwalające na korelację odpowiedzi (np. CorrelationId lub nazwę kolejki odpowiedzi). Usługa odbierająca żądanie przetwarza je w swoim tempie i publikuje wynik do Response Queue, z której klient odbiera odpowiedź.

Takie podejście zapewnia: 

• brak blokowania zasobów po stronie klienta,
• odporność na opóźnienia i chwilową niedostępność usług,
• lepszą skalowalność w porównaniu do komunikacji synchronicznej.

Request–Response Pattern sprawdza się szczególnie w scenariuszach, gdzie odpowiedź jest wymagana, ale nie musi być natychmiastowa – np. w integracjach między mikroserwisami, procesach długotrwałych czy komunikacji pomiędzy systemami o różnej wydajności. W połączeniu z mechanizmami Azure Service Bus, takimi jak retry i dead-letter queue, wzorzec ten pozwala budować niezawodne i elastyczne rozwiązania komunikacyjne.

Outbox Pattern

Outbox Pattern to wzorzec architektoniczny, który rozwiązuje problem spójności pomiędzy zapisem danych a publikacją komunikatu. W systemach opartych na komunikatach często pojawia się ryzyko, że dane zostaną zapisane w bazie, ale zdarzenie nie trafi do brokera (lub odwrotnie). Outbox Pattern eliminuje ten problem.

W praktyce, zamiast wysyłać komunikat bezpośrednio do Azure Service Bus, aplikacja zapisuje go najpierw do tabeli Outbox w tej samej transakcji co dane biznesowe. Dzięki temu zapis danych i „intencja wysłania komunikatu” stają się operacją atomową. Osobny proces (np. background worker) odczytuje wpisy z Outboxa i publikuje je do Azure Service Bus.

Takie podejście zapewnia:

• brak utraty komunikatów,
• odporność na awarie sieci i brokera,
• możliwość bezpiecznego ponowienia wysyłki.

Outbox Pattern jest szczególnie przydatny w architekturze mikroserwisów i systemach event-driven, gdzie zdarzenia domenowe muszą być publikowane w sposób pewny i powtarzalny. W połączeniu z mechanizmami Azure Service Bus, takimi jak ponowienia wysyłki czy deduplikacja, stanowi solidną podstawę do budowy niezawodnej komunikacji między systemami. Outbox Pattern szczególnie dobrze współpracuje z bazami danych wspierającymi transakcje, pozwalając na spójne zapisanie danych biznesowych i komunikatu w jednym kroku.

Inbox Pattern

Inbox Pattern to wzorzec architektoniczny, który rozwiązuje problem wielokrotnego przetwarzania tego samego komunikatu. W systemach opartych na komunikatach – takich jak Azure Service Bus – ponowne dostarczenie komunikatu jest zachowaniem poprawnym (np. po błędzie lub timeoutach), dlatego aplikacja musi być na to przygotowana.

W praktyce każdy odebrany komunikat jest najpierw rejestrowany w Inboxie – najczęściej w postaci zapisu jego unikalnego identyfikatora (MessageId) w bazie danych. Dopiero jeśli komunikat nie był wcześniej przetwarzany, trafia on do logiki biznesowej. Duplikaty są bezpiecznie ignorowane, co zapewnia idempotentność operacji.

Inbox Pattern zapewnia:

• ochronę przed skutkami retry i ponownych dostarczeń,
• spójność danych w przypadku awarii podczas przetwarzania,
• możliwość bezpiecznego skalowania konsumentów.

Monitoring i diagnostyka: Azure Service Bus Alerts i integracja z Application Insights

Skuteczne wykorzystanie Azure Service Bus w środowisku produkcyjnym wymaga odpowiedniego monitoringu i diagnostyki, które pozwalają szybko reagować na problemy z przetwarzaniem komunikatów. Platforma Azure udostępnia w tym zakresie gotowe mechanizmy oparte o Azure Monitor.

Azure Service Bus publikuje szereg metryk, takich jak liczba aktywnych komunikatów, długość dead-letter queue czy czas przetwarzania. Na ich podstawie można konfigurować Alert Rules, które automatycznie powiadomią zespół o potencjalnych problemach, np. rosnącej liczbie komunikatów w kolejce lub błędach po stronie konsumentów.

Dla głębszej diagnostyki Service Bus integruje się z Application Insights, umożliwiając śledzenie komunikatów w kontekście całego przepływu aplikacji. Dzięki korelacji telemetrycznej możliwe jest przeanalizowanie, jak komunikat przechodzi przez kolejne komponenty systemu i gdzie pojawiają się opóźnienia lub błędy.

Połączenie alertów, metryk i telemetryki aplikacyjnej pozwala nie tylko reagować na incydenty, ale także proaktywnie wykrywać problemy, zanim wpłyną one na użytkowników końcowych.

Zabezpieczenia w Azure Service Bus – RBAC, SAS i protokół AMQP

Azure Service Bus oferuje mechanizmy bezpieczeństwa klasy enterprise, które pozwalają precyzyjnie kontrolować dostęp do komunikatów i chronić komunikację pomiędzy komponentami systemu. Usługa wspiera zarówno nowoczesne uwierzytelnianie oparte o Azure Active Directory, jak i tradycyjne mechanizmy kluczy dostępowych.

RBAC (Role-Based Access Control) umożliwia zarządzanie uprawnieniami przy użyciu ról przypisanych do użytkowników, aplikacji i tożsamości zarządzanych. Pozwala to na centralne i spójne zarządzanie dostępem do kolejek, tematów i subskrypcji, bez konieczności przechowywania wrażliwych danych, takich jak hasła czy klucze dostępu, w kodzie aplikacji. W kontekście Azure Service Bus można stosować predefiniowane role – między innymi Data Owner, Data Sender i Data Receiver – które pozwalają na granularne zarządzanie dostępem do wysyłania, odbioru lub pełnego zarządzania zasobami komunikacyjnymi.

Alternatywą lub uzupełnieniem RBAC są SAS (Shared Access Signatures), czyli tokeny dostępu z określonym zakresem uprawnień i czasem ważności. SAS sprawdzają się w scenariuszach integracyjnych, gdzie wymagany jest ograniczony i kontrolowany dostęp do zasobów Service Bus.

Komunikacja z Azure Service Bus odbywa się z wykorzystaniem protokołu AMQP 1.0, który zapewnia wysoką wydajność, niezawodność oraz wsparcie dla scenariuszy enterprise. AMQP umożliwia stabilne połączenia, efektywne przesyłanie komunikatów i pełne wykorzystanie zaawansowanych funkcji usługi. Azure Service Bus obsługuje również protokół HTTP jako alternatywę dla AMQP w przypadku aplikacji, które nie wspierają AMQP. Zaleca się jednak korzystanie z AMQP w przypadku systemów wymagających niskiej latencji i trwałych połączeń.

Połączenie RBAC, SAS i AMQP pozwala budować bezpieczne, skalowalne i zgodne z najlepszymi praktykami rozwiązania komunikacyjne w chmurze Azure.

Podsumowanie – co warto zapamiętać?

Azure Service Bus to kluczowe narzędzie komunikacyjne w chmurze Microsoft Azure, pozwalające na tworzenie nowoczesnych aplikacji opartych na architekturze asynchronicznej. Dzięki bogatemu zestawowi funkcji – takich jak kolejki, tematy i subskrypcje, sesje, oraz wsparcie dla wzorców projektowych (Request-Response,
Outbox, Inbox) – usługa umożliwia skalowalność, niezawodność i elastyczność systemów.

Zintegrowane mechanizmy bezpieczeństwa (RBAC, SAS, AMQP) oraz zaawansowane monitorowanie (Application Insights, Azure Monitor) gwarantują pełną kontrolę i stabilność rozwiązania, czyniąc je niezbędnym elementem w ekosystemie
nowoczesnych aplikacji chmurowych.

Jeżeli temat cię zaciekawił i chcesz korzystać z usługi w swoim projekcie, zajrzyj do Microsoft Learn na Azure Portal, by uzyskać więcej informacji.

Często zadawane pytania:

Przejdź do:

1. 1. SCSS vs CSS – podstawy 
2. 2. Instalacja Webpacka 
3. 3. Instalowanie Gulpa 
4. 4. Konfiguracja Webpacka 
5. 5. Konfiguracja Gulpa 
6. 6. Obsługa narzędzi Gulp vs Webpack – porównanie 
7. 7. Które narzędzie wybrać: Gulp czy Webpack?
8. 8. Gulp vs Webpack – podsumowanie  

Webpack vs Gulp… Oba te narzędzia odgrywają ważną rolę w świecie programistycznym. Wybór między nimi często na pierwszy rzut oka wydaje się trudny. Zwłaszcza na początku przygody z programowaniem. Jednak jeśli poznamy ich różnice i podobieństwa, z pewnością będzie łatwiej podjąć właściwą decyzję.

Bez względu na to, czy rozważasz użycie Gulpa (task runner), Webpacka (module bundler), czy może kombinacji obu, znajomość ich funkcjonalności z pewnością ułatwi ci pracę i zwiększy produktywność. Jeśli zatem szukasz odpowiednich narzędzi do swojego projektu, koniecznie przeczytaj ten artykuł.

SCSS vs CSS – podstawy  

Zanim porównam narzędzia Webpack i Gulp, przypomnijmy sobie, czym są technologie CSS i SCSS. Są one niezbędne w programowaniu na front-endzie.

CSS i SCSS to technologie, których na co dzień używamy do przypisywania konkretnych wyglądów do elementów (kolor, rozmiar) i rozmieszczania tych elementów na stronie. Ważne jest jednak, aby przed podjęciem decyzji o skorzystaniu z wybranej z nich wziąć pod uwagę pewne różnice.

 CSS to standardowy język arkuszy stylów, mający ugruntowaną pozycję w świecie front-endowym. W porównaniu z SCSS jego składnia wydaje się prostsza i o wiele bardziej intuicyjna. Młodsi programiści zdecydowanie stawiają na CSS, szczególnie na wczesnym etapie nauki. Reguły CSS mają na celu zdefiniowanie stylów dla określonych elementów, takich jak paragrafy, divy czy inne elementy HTML.

/* Składnia CSS */  

h1 { color: blue; font-size: 24px; } 

SCSS jest niczym innym jak preprocesorem CSS, to znaczy rozszerza składnię o dodatkowe funkcje i pozwala na wykorzystanie zaawansowanych technik, w tym takich jak: 

• reguły zagnieżdżania – selektory CSS można zagnieżdżać w innych, odzwierciedlając strukturę selektorów HTML. 
• użycie zmiennych (które umożliwiają przechowywanie wartości wielokrotnego użytku w arkuszu stylów), 
• operatory matematyczne (pozwalające na dodawanie, odejmowanie, mnożenie i dzielenie wartości w stylach), dzięki czemu jest łatwiej pisać kod i staje się on bardziej modułowy i po prostu elegancki. 

/* Składnia SCSS z zagnieżdżaniem i zmiennymi */ 

$primary-color: blue; 

  

h1 {  

  kolor: $primary-color; 

  font-size: 24px; 

} 

Kluczowe różnice między SCSS i CSS:  

1. Składnia: SCSS oferuje bardziej rozszerzoną składnię, co ułatwia pisanie i utrzymanie kodu. Reguły zagnieżdżania pozwalają pisać bardziej czytelny i logiczny kod.  
2. Zmienne: SCSS umożliwia definiowanie zmiennych, ułatwiając zmienianie wartości stylu w jednym miejscu i tym samym przyczyniając się do spójności w całym projekcie. 
3. Preprocesor: SCSS jest jednym z wielu preprocesorów CSS (to znaczy, że kod SCSS musi zostać skompilowany do zwykłego CSS przed wdrożeniem na stronie internetowej).  

Wybór między SCSS i CSS zależy od tego, na ile złożony jest projekt i jakie są umiejętności zespołu projektowego. W przypadku niezłożonych projektów, które nie wymagają zaawansowanych technik ostylowania, CSS może okazać się odpowiednim wyborem. Jednak w przypadku bardziej złożonych projektów, które wymagają modułowości i łatwego edytowania, SCSS pozwoli na większą elastyczność i wygodę w zarządzaniu stylami.  

Przeczytaj także: 

• Marble testing. Testowanie RxJS  
• Jeśli nie Redux, to co? Zarządzanie stanem aplikacji w React 
   

Instalacja Webpacka  

Funkcje Webpacka pozwalają przede wszystkim na zarządzanie zależnościami i porządkowanie plików. Instalacja narzędzia to naprawdę “bułka z masłem”. Zaczynamy od sprawdzenia, czy jest już zainstalowany Node Package Manager (NPM), który moim zdaniem umożliwia najskuteczniejszą i najszybszą instalację Webpacka. Następnie otwieramy wiersz poleceń i wpisujemy:  

npm install webpack –g 

Z wiersza poleceń przechodzimy do katalogu z naszym projektem i wpisujemy polecenie:  

npm init 

Możemy tu zauważyć, że w katalogu docelowym został utworzony plik package.json. Nie pozostaje nic innego, jak tylko zainstalować Webpacka w naszym projekcie:  

npm install --save-dev webpack 

A teraz już możemy cieszyć się ogromnymi możliwościami narzędzia!  

W dalszych krokach konfiguracja zależy od potrzeb konkretnego projektu – w punktach poniżej opiszę przykładową, krótką konfigurację. Szczegółowe wytyczne dotyczące możliwości Webpacka można znaleźć w oficjalnej dokumentacji na stronie: Webpack Documentation.  

Instalowanie Gulpa  

Gulp stosuje się do automatyzacji niektórych zadań, takich jak kompilacja, minifikacja plików, obrazów lub odświeżanie przeglądarki. Instalacja Gulpa jest tak samo łatwa jak w przypadku Webpacka. Upewniamy się, że mamy zainstalowany NPM. I zaczynamy od polecenia:  

npm install -g gulp 

Przechodzimy do naszego katalogu projektów, potem tworzymy plik package.json za pomocą polecenia:  

npm init 

Wystarczy teraz dodać Gulpa do naszego projektu:  

npm install ---save-dev gulp  

Jak skonfigurować Webpacka? Po instalacji możemy przystąpić do tworzenia pliku gulpfile.js. Będzie on odpowiadał za konfigurację zadań dla naszego narzędzia. W dalszej części przedstawię również krótką konfigurację dla Gulpa.  

Aby poznać wszystkie możliwości Gulpa, skorzystaj z dostępnej dokumentacji. 

Konfiguracja Webpacka   

Jak wspomniałem wcześniej, przedstawię krótką konfigurację Webpacka. Narzędzie jest na tyle zaawansowane, że nie da rady opisać tu wszystkich jego możliwości.  

Zacznijmy od dodania pliku webpack.config.js, który zawiera całą konfigurację Webpacka.  

Następnie umieśćmy tam podstawową konfigurację:  

module.exports = { 

  entry: './src/main.js', 

  output: { 

    path: __dirname + '/dist',  

    filename: 'bundle.js'  

  },  

  mode: 'production' 

};

Zdefiniowaliśmy, skąd Webpack ma pobierać pliki źródłowe (entry). Output określa, gdzie powinny być umieszczone po przetworzeniu. Opcja mode określa, czy chcemy zoptymalizować kod, na przykład pod kątem produkcji. Webpack zapewnia szeroki pakiet wtyczek i loaderów, co pozwala dostosować go do naszych potrzeb.  

Konfiguracja Gulpa   

Gulp to narzędzie do automatyzacji zadań, które możemy odpowiednio dostosować w pliku gulpfile.js. W czasie konfiguracji definiujemy takie zadania, jak: minifikacja kodu, kompilacja czy odświeżanie przeglądarki po każdej zmianie w kodzie.  

const gulp = require('gulp'); 

const uglify = require('gulp-uglify'); 


gulp.task('compress', function() {  

  return gulp.src('src/js/*.js') 

    .pipe(uglify()) 

    .pipe(gulp.dest('dist/js')); 

});

To przykładowa konfiguracja mająca za zadanie skompresowanie plików JavaScript.  

Zaczynamy od stworzenia nowego zadania o nazwie „Compress”. Następnie, za pomocą returngulp.src (’src/js/*.js’), określamy pliki źródłowe do przetworzenia (w naszym przypadku będą to wszystkie pliki z rozszerzeniem .js, z katalogu src/js). 

Kolejny krok to przekazanie plików źródłowych do wtyczki za pomocą pipe(uglify()), który kompresuje kod, usuwając np. zbędne spacje, komentarze, tak aby plik był możliwie jak najmniejszy. 

Na koniec wskazujemy katalog do zapisywania przetworzonych plików.  

Obsługa narzędzi Gulp vs Webpack – porównanie  

Jeśli miałbym porównać Webpack i Gulp, trudno wskazać jeden słuszny wybór – wszystko zależy od projektu, w którym pracujemy. 

Webpack to w głównej mierze pakiet do kompilacji zasobów projektu, tak aby zyskać przejrzystość. Dzięki wtyczkom można łatwo go rozszerzyć i zyskać wachlarz zastosowań, takich jak:  

• Transpilacja – w przypadku JavaScript np. dostosowanie wersji ES6 do starszych przeglądarek 
• Minifikacja kodu (usuwanie niepotrzebnych znaków z kodu, aby zmniejszyć rozmiar, a tym samym poprawić czas ładowania) 
• Zarządzanie zależnościami 

Sprawdź, jakie wtyczki są dostępne dla Gulpa: Korzystanie z wtyczki   

Gulp to jednak także narzędzie do automatyzacji zadań, które bardzo usprawnia przepływ pracy. Moim zdaniem bardzo łatwo nauczyć się korzystać z tego narzędzia. Całkiem szybko możemy zacząć tworzyć zadania dla kompilacji plików SASS lub automatycznego odświeżania przeglądarki. Konfiguracja jest o wiele bardziej czytelna i elastyczna.  

Webpack doskonale radzi sobie z zależnościami, natomiast Gulp wyróżnia się na tle innych narzędzi, jeśli chodzi o pełną automatyzację pracy (jeśli na tym ci właśnie zależy).  

W skrócie:  

• Webpack pozwala na łączenie modułów. Ale też, tak jak Gulp, umożliwia uruchamianie wielu funkcji dotyczących zadań 

• Gulp to narzędzie do automatyzowania zadań, które usprawnia przepływ pracy 

Które narzędzie wybrać: Gulp czy Webpack?   

Wybór pomiędzy nimi zależy od konkretnych potrzeb i architektury naszego projektu. To też kwestia prywatnych preferencji i doświadczenia. Jeśli łączenie i zarządzanie zależnościami są złożone i będą istotne w procesie rozwoju oprogramowania, Webpack może okazać się właściwym rozwiązaniem. Z drugiej strony, jeśli potrzebujmy prostego i czytelnego sposobu na automatyzację typowych zadań programistycznych, Gulp będzie do tego doskonały.  

Pamiętaj, że nic nie stoi na przeszkodzie, aby oba narzędzia połączyć. Korzystanie z Gulpa i Webpacka jednocześnie oznacza dostęp do zalet każdego z nich. Wpłynie to pozytywnie nie tylko jakość projektu, ale też pozwoli skrócić czas potrzebny na rozwój oprogramowania.    

Użycie Webpacka zamiast Gulpa 

W połączeniu ze skryptami NPM Webpack może z powodzeniem zastąpić Gulpa. Z mojego doświadczenia wynika jednak, że lepiej łączyć narzędzia, niż ograniczać się tylko do jednego, do czego was zachęcam. Jak już wspomniałem, Webpack i Gulp to narzędzia do budowania (build tools), które można wykorzystywać do podobnych zadań. Cechują się jednak różnymi podejściami i każde z nich ma inne mocne strony.  

Koniec końców wybór między korzystaniem z samego Webpacka lub połączeniem go z Gulpem będzie zależeć od twojego projektu i twoich własnych preferencji programistycznych.  

Gulp vs Webpack – podsumowanie   

Mam nadzieję, że udało mi się przemycić w artykule korzyści płynące z używania Webpacka i Gulpa. Co do pytania „Webpack czy Gulp?”, tu nie ma idealnej odpowiedzi, zwłaszcza jeśli jesteś początkującym front-end developerem. Ten artykuł to tak naprawdę wprowadzenie do tych narzędzi – na każdym etapie warto wspierać się dokumentacją, wiedzą doświadczonych kolegów z projektu, a także Technical Leaderów.   

Dokonując wyboru, najlepiej skupić się na swoich umiejętnościach, doświadczeniu i potrzebach projektowych. Nie ma uniwersalnego rozwiązania. Często ekosystem jest narzucany odgórnie. Warto więc eksperymentować z obiema technologiami, łączyć je, testować i tworzyć zoptymalizowane, wydajne środowisko.  

PRZEJDŹ DO:

1. 1. RxJS observables
2. 2. Czym jest testowanie RxJS (marble testing w RxJS)?
3. 3. Jak pisać przypadki testowe RxJS?
4. 4. Czym jest marble diagram w RxJS?
5. 5. Jakie są rodzaje testów marble w RxJS?
6. 6. Jakie są korzyści z testowania RxJS?
7. 7. FAQ

RxJS observables

RxJS to biblioteka do tworzenia asynchronicznych strumieni danych, zarządzania nimi oraz obsługiwania zdarzeń w aplikacjach JavaScript. Kluczowym elementem RxJS są observable, które reprezentują strumienie danych emitowane w czasie.

Observable opierają się na wzorcu projektowym Obserwator, w którym obserwator „subskrybuje” obserwowany obiekt i oczekuje na emitowane przez niego dane. RxJS oferuje różnorodne operatory, takie jak map, filter czy merge, które pozwalają na przekształcanie, filtrowanie i łączenie strumieni danych.

Szerzej koncepcja biblioteki RxJS została opisana w artykule Programowanie reaktywne z JavaScript w RxJS.

Czym jest testowanie RxJS (marble testing w RxJS)?

RxJS umożliwia reaktywne programowanie w JavaScript, dzięki czemu można obsługiwać asynchroniczne strumienie danych oraz manipulować nimi za pomocą różnych operacji, takich jak mapowanie, filtrowanie czy łączenie. Testowanie RxJS ma na celu zapewnienie, że kod działający na tych strumieniach jest poprawny, wolny od błędów i spełnia oczekiwania. 

Marble testing 

W kontekście testowania RxJS warto wspomnieć o marble testing, które jest jednym z popularnych narzędzi do testowania strumieni danych w tej bibliotece. Marble testing to nic innego jak wizualizacja strumieni danych za pomocą tzw. marble diagrams. W marble strumienie danych reprezentowane są jako ciągi znaków, gdzie każdy znak symbolizuje wartość w strumieniu lub specjalne zdarzenie, takie jak zakończenie strumienia czy wystąpienie błędu. Testowanie z użyciem diagramów marble pozwala na definiowanie oczekiwanych wyników oraz porównywanie ich z rzeczywistymi wynikami testowania, co jest szczególnie przydatne w przypadku złożonych operacji asynchronicznych. 

Rodzaje testów

Testowanie RxJS, zwłaszcza z wykorzystaniem diagramów marble, pozwala na weryfikację poprawności działania funkcji i operatorów reaktywnych w kontekście testów jednostkowych. Testy jednostkowe koncentrują się na ocenie pojedynczych funkcji, operatorów oraz strumieni danych. Ich celem jest izolowanie poszczególnych elementów kodu i sprawdzenie, czy zachowują się zgodnie z oczekiwaniami.

Przeczytaj także: Narzędzia automatyzacji testów czy dobre praktyki? Jak przyspieszyć testowanie?

Narzędzia testowania RxJS 

W celu ułatwienia testowania z użyciem diagramów marble biblioteka RxJS udostępnia takie narzędzia jak TestScheduler, który pozwala na kontrolowanie czasu w wirtualny sposób – bez wpływu na rzeczywisty czas wykonywania testów. TestScheduler umożliwia definiowanie wartości wejściowych i oczekiwanych wartości wyjściowych za pomocą marble diagrams, a następnie symuluje przepływ danych w strumieniach reaktywnych. 

Jak pisać przypadki testowe RxJS?  

Pisanie przypadków testowych RxJS wymaga starannego planowania, zrozumienia kodu źródłowego oraz wykorzystania odpowiednich narzędzi do testowania. Marble testing to jedno z podejść, które pomaga w tworzeniu przejrzystych testów dla strumieni danych. Oto kilka wskazówek, jak napisać testy dla kodu opartego na bibliotece RxJS: 

1. Zapoznaj się z kodem źródłowym 

Przed przystąpieniem do pisania przypadków testowych dokładnie zapoznaj się z kodem źródłowym, który będzie testowany. Zrozumienie struktury kodu oraz celu poszczególnych funkcji i operatorów pozwoli na opracowanie skutecznych i kompleksowych testów. 

2. Wybierz odpowiedni framework do testowania 

Wybierz framework do testowania kodu JavaScript, taki jak Jasmine, Mocha czy Jest, który najlepiej odpowiada twoim potrzebom i preferencjom. Upewnij się, że wybrany framework współpracuje z RxJS i pozwala na wykorzystanie marble testing, jeśli planujesz korzystać z tego podejścia. 

3. Utwórz strukturę testów 

Testy jednostkowe zwykle są organizowane w blokach describe (lub podobnych, w zależności od używanego frameworka), które służą do grupowania testów dotyczących określonej funkcji, operatora lub komponentu. Wewnątrz bloków describe umieszczamy poszczególne przypadki testowe, zdefiniowane za pomocą funkcji it (lub odpowiednika w wybranym frameworku). 

4. Zastosuj marble testing 

Marble testing to podejście, które pozwala na wizualizację strumieni danych za pomocą tzw. marble diagrams. W marble testing strumienie danych reprezentowane są jako ciągi znaków, gdzie każdy znak symbolizuje wartość w strumieniu lub specjalne zdarzenie, takie jak zakończenie strumienia czy wystąpienie błędu. 

W przypadku testowania RxJS z wykorzystaniem marble testing użyj narzędzi dostarczanych przez bibliotekę, takich jak TestScheduler. TestScheduler pozwala na kontrolowanie czasu w sposób wirtualny oraz definiowanie wartości wejściowych i oczekiwanych wartości wyjściowych za pomocą marble diagrams.  

5. Zdefiniuj przypadki testowe 

Przypadki testowe powinny być zdefiniowane w sposób czytelny i zrozumiały, opisując oczekiwane zachowanie funkcji, operatora lub strumienia danych. Wykorzystując marble testing, możesz precyzyjnie i czytelnie opisać oczekiwane zachowanie strumieni danych oraz porównać rzeczywiste wyniki z oczekiwanymi. 

6. Testuj różne przypadki i scenariusze 

Podczas pisania przypadków testowych warto przetestować różne scenariusze, takie jak: 

• Przepływ danych o różnych wartościach 
• Przepływ danych z opóźnieniami lub interwałami 
• Zachowanie kodu w przypadku wystąpienia błędów 
• Zakończenie strumieni danych 
• Właściwe przekazywanie wartości do kolejnych operatorów 

• Spróbuj także uwzględnić przypadki brzegowe, aby upewnić się, że testowany kod jest odporny na różne sytuacje. 

7. Przeglądaj i ulepszaj przypadki testowe 

Regularnie przeglądaj swoje przypadki testowe, aby upewnić się, że są aktualne i nadal spełniają swoje zadanie. Spróbuj zoptymalizować testy, eliminując powtarzalne lub zbędne fragmenty kodu, a także ułatwiając jego czytanie i zrozumienie. Dzięki temu utrzymanie i rozwój testów będą łatwiejsze w miarę wprowadzania zmian w kodzie źródłowym. 

Pisanie przypadków testowych RxJS, zwłaszcza z wykorzystaniem marble testing, wymaga zrozumienia struktury kodu, wyboru odpowiedniego frameworka do testowania, tworzenia struktury testów oraz definiowania przypadków testowych, które precyzyjnie opisują oczekiwane zachowanie strumieni danych. Dzięki stosowaniu tych wskazówek będziesz w stanie tworzyć czytelne i skuteczne testy jednostkowe dla swojego kodu opartego na bibliotece RxJS. 

Czym jest marble diagram w RxJS? 

Diagramy marble to wizualne reprezentacje strumieni danych w bibliotece RxJS, które pomagają zrozumieć przepływ danych oraz interakcje między operacjami na strumieniach. Wprowadzenie diagramów marble do procesu wytwarzania oprogramowania z RxJS może poprawić czytelność kodu, ułatwić komunikację między programistami oraz przyspieszyć proces wdrażania testów. 

Jak odczytywać diagramy marble w RxJS? 

Diagramy marble używają znaków do przedstawienia wartości emitowanych przez strumień, zakończenia strumienia, wystąpienia błędu oraz subskrypcji i jej anulowania. Oto kilka dodatkowych wskazówek, jak odczytywać diagramy: 

Czas: każdy myślnik (–) oznacza jednostkę czasu, zwaną również „ramką”. W testach marble długość ramki czasowej jest zdefiniowana w narzędziu TestScheduler, co pozwala na kontrolowanie upływu czasu w teście. 

Wartości: znaki alfanumeryczne (np. a, b, c) reprezentują wartości emitowane przez strumień danych. Wartości te są zazwyczaj zdefiniowane w obiekcie wartości przekazywanym do metody toBe(), który mapuje te znaki na rzeczywiste wartości. 

Subskrypcja i anulowanie subskrypcji: w Marble możemy użyć symbolu ^ do oznaczenia momentu, w którym subskrypcja się rozpoczyna, oraz ! do oznaczenia momentu, w którym zostaje anulowana. 

Przykładowy diagram marble dla RxJS może wyglądać tak:

---a---b---c---| 
 

Ten diagram reprezentuje strumień danych, który emituje trzy wartości: a, b, c, każda z nich emitowana w równych odstępach czasu. Ostatni symbol, |, oznacza, że strumień został zakończony po emisji c.

---a---b---c---| 

        map(x => x.toUpperCase()) 

---A---B---C---| 

W tym przypadku mamy strumień wejściowy, który emituje wartości a, b, c. Następnie zastosowaliśmy operator map, który przekształca każdą emitowaną wartość na jej odpowiednik z dużą literą. Wynikowy strumień emituje więc wartości A, B, C. 

Diagramy marble mogą być znacznie bardziej skomplikowane, z wieloma operatorami i zdarzeniami. Kluczowe jest zrozumienie podstawowej notacji, aby móc interpretować i tworzyć takie diagramy. 

Jakie są rodzaje testów marble w RxJS?

Testy marble w RxJS dzielimy na dwa główne rodzaje: testy jednostkowe i testy integracyjne.

Testy jednostkowe

Skupiają się na izolowaniu i testowaniu indywidualnych komponentów, operatorów lub funkcji. Marble testing jest bardzo przydatne w testach jednostkowych, ponieważ pozwala na precyzyjne sprawdzanie sekwencji zdarzeń oraz efektów poszczególnych operatorów na strumieniach danych. W testach jednostkowych korzystamy z TestScheduler, który pozwala kontrolować upływ czasu oraz weryfikować oczekiwane wyniki testów.

Testy integracyjne

Testują interakcje między różnymi komponentami, operatorami lub funkcjami w systemie. Marble testing może być również używane w testach integracyjnych, aby zbadać, jak różne części kodu współpracują ze sobą. W testach integracyjnych sprawdzamy, czy przepływ danych między różnymi komponentami jest zgodny z oczekiwaniami. Testowanie marble w kontekście testów integracyjnych jest bardziej złożone niż w przypadku testów jednostkowych, ale może dostarczyć cenne informacje na temat zachowania systemu jako całości. 

W testowaniu z wykorzystaniem diagramów marble  istotne jest również zrozumienie operatorów „hot” i „cold”. W kontekście strumieni danych operator „hot” to taki, który emituje wartości niezależnie od tego, czy istnieje obecnie jakakolwiek subskrypcja. Z kolei operator „cold” zaczyna emitować wartości dopiero po subskrypcji. W testach marble operator „cold” jest zazwyczaj reprezentowany przez strumienie oznaczone jako source. Najlepiej będzie spojrzeć na przykład:  

import { TestScheduler } from 'rxjs/testing'; 

import { of, Subject } from 'rxjs'; 

import { map, takeUntil } from 'rxjs/operators'; 
 

it('should demonstrate hot and cold observables', () => { 

  const testScheduler = new TestScheduler((actual, expected) => { 

    expect(actual).toEqual(expected); 

  }); 

 

  testScheduler.run(({ cold, hot, expectObservable }) => { 

    const sourceCold$ = cold(' --a--b--c--|'); 

    const sourceHot$ = hot('  --d--e--f--|'); 

    const stop$ = cold('      -----s--|'); 

    const expectedMarble = '  --x--y--(z|)'; 

 

    const resultCold$ = sourceCold$.pipe( 

      takeUntil(stop$), 

      map((value) => value.toUpperCase()) 

    ); 

    const resultHot$ = sourceHot$.pipe( 

      takeUntil(stop$), 

      map((value) => value.toUpperCase()) 

    ); 

    expectObservable(resultCold$).toBe(expectedMarble, { 

      x: 'A', 

      y: 'B', 

      z: 'C' 

    }); 

    expectObservable(resultHot$).toBe(expectedMarble, { 

      x: 'D', 

      y: 'E', 

      z: 'F' 

    }); 

  }); 

}); 

W powyższym przykładzie widzimy dwa strumienie danych: „cold” i „hot”. Strumień „cold” zaczyna emitować wartości tylko po subskrypcji, podczas gdy strumień „hot” emituje wartości niezależnie od subskrypcji. W teście używamy operatora „takeUntil” do zakończenia obserwacji strumieni danych w odpowiednim momencie. 

Podsumowując, marble diagrams w RxJS są niezwykle pomocne w zrozumieniu przepływu danych oraz zachowań poszczególnych operatorów w strumieniach danych. Testowanie marble ułatwia tworzenie testów jednostkowych oraz integracyjnych, które są niezbędne dla poprawnego działania aplikacji opartej na RxJS. Wiedza na temat diagramów marble oraz umiejętność pisania skutecznych testów marble są ważnymi kompetencjami każdego programisty korzystającego z biblioteki RxJS. 

W przypadku pracy z marble warto pamiętać o kilku dodatkowych zasadach i wskazówkach, które mogą ułatwić proces testowania:

• Konwencje nazewnictwa: kiedy tworzysz strumienie danych za pomocą diagramów marble, warto utrzymywać konwencje nazewnictwa i używać nazw związanych z funkcjonalnością strumieni. Dzięki temu możemy łatwo zrozumieć, jakie dane przepływają przez strumienie, co ułatwia analizowanie wyników testów. 

• Korzystanie z helperów: w wielu przypadkach testowania marble możemy skorzystać z funkcji pomocniczych dostarczanych przez bibliotekę RxJS, takich jak TestScheduler, hot, cold, time, expectObservable i expectSubscriptions. Te funkcje ułatwiają tworzenie diagramów marble oraz zarządzanie nimi i testowanie przepływu danych między różnymi strumieniami. 
• Weryfikacja wyników testów: podczas pisania testów marble warto zwracać uwagę na wyniki testów i błędy zgłaszane przez narzędzia do testowania, takie jak Jasmine lub Mocha. Dzięki temu możemy szybko zidentyfikować i naprawić błędy w naszym kodzie. 
• Dokładność testów: testowanie marble pozwala na precyzyjne śledzenie sekwencji zdarzeń w strumieniach danych. Jednak ważne jest, aby pamiętać, że testowanie marble nie zastępuje innych rodzajów testowania, takich jak testy jednostkowe czy integracyjne. Warto korzystać z różnych technik testowania w zależności od kontekstu i potrzeb aplikacji. 
• Praktyka: testowanie marble może być na początku trudne do zrozumienia, ale z biegiem czasu i nabieranym doświadczeniem staje się coraz łatwiejsze. Praca z różnymi przykładami i scenariuszami pomoże zrozumieć, jak najlepiej wykorzystać diagramy marble w testach RxJS. 

Używając marble w RxJS, można skutecznie testować strumienie danych oraz interakcje między operacjami. Diagramy marble ułatwiają zrozumienie przepływu danych oraz oczekiwanych wyników testów, co prowadzi do budowania bardziej niezawodnych i wydajnych aplikacji. Praktyka i doświadczenie są kluczowe w opanowaniu testowania marble, ale korzyści płynące z jego zastosowania są nieocenione dla każdego programisty Front-End.

Przeczytaj także: Test regresji – strata czasu czy must have w projekcie?

Jakie są korzyści z testowania RxJS?

• Działanie kodu zgodne z oczekiwaniami – testowanie kodu RxJS jest niezwykle ważne, gdyż pozwala na zwiększenie pewności, że kod działa zgodnie z oczekiwaniami. Dzięki testom programiści mogą być pewni, że ich aplikacje rzeczywiście spełniają założone wymagania biznesowe, co przekłada się na mniejsze ryzyko wystąpienia błędów czy niezgodności. 
• Wykrywanie błędów – jednocześnie testowanie ułatwia wykrywanie błędów, ponieważ sprawdza indywidualne funkcje, operatory oraz interakcje między nimi. Dzięki temu możliwe jest szybsze zidentyfikowanie i naprawienie problemów w kodzie. To wpływa również na skrócenie czasu debugowania, gdyż testy pomagają programistom szybko zlokalizować źródło błędu. 
• Łatwiejsze wprowadzanie zmian – testy RxJS wspierają także wprowadzanie zmian w kodzie, gdyż automatycznie sprawdzają funkcjonalność po każdej modyfikacji. Dzięki temu programista może szybciej wykryć i naprawić ewentualne problemy wynikające z wprowadzonych zmian. Ponadto testy ułatwiają refaktoryzację, gdyż programista może być pewny, że jego zmiany nie wprowadzą regresji. 
• Dokumentacja kodu – warto również zauważyć, że testy RxJS często służą jako dokumentacja dla kodu, dostarczając informacji o tym, jak korzystać z poszczególnych funkcji i jakie są ich oczekiwane wyniki. Taka dokumentacja jest nieoceniona dla innych programistów, którzy chcą zrozumieć czyjś kod i wiedzieć, jak go używać. 

• Większe zaufanie do oprogramowania – wreszcie testowanie zwiększa zaufanie do kodu zarówno wśród programistów, jak i interesariuszy projektu. Wszyscy mogą być pewni, że aplikacja rzeczywiście działa poprawnie i spełnia wymagania. Testy są kluczowe dla utrzymania wysokiej jakości aplikacji opartych na strumieniach danych i reaktywnym programowaniu. 
• Lepszy kod – w efekcie testowanie kodu RxJS przyczynia się do lepszej jakości kodu, szybszego wykrywania i naprawiania błędów, łatwiejszego wprowadzania zmian oraz wzrostu zaufania do kodu. Jako ekspert od RxJS, zdecydowanie polecam stosowanie testów we wszelkich projektach opartych na tej bibliotece. 

FAQ

Przejdź do:

1. 1. Wybór architektury
2. 2. Architektura a dług technologiczny
3. 3. Czym jest Clean Architecture
4. 4. Idea Clean Architecture
5. 5. Clean Architecture – wzorce projektowe
6. 6. Application
7. 7. Presentation
8. 8. Domain
9. 9. Data
10. 10. Wady Clean Architecture
11. 11. Zalety Clean Architecture
12. 12. W jakich projektach stosować Clean Architecture?
13. 13. Podsumowanie

Wybór architektury

Rozpoczynając nowy projekt, developerzy chcą bardzo szybko zakończyć pierwsze zadanie, pomijając wagę przygotowania projektu. To błąd! Przecież to właśnie początkowy etap tworzenia nowej aplikacji jest najważniejszy. Pozwala on wypracować spójne, stałe podejście dla pozostałych developerów biorących udział w projekcie.

Czytaj także: Neo4j – zaproszenie do grafowych baz danych

Architektura a dług technologiczny

Kolejnym błędem popełnianym przez developerów jest doprowadzenie do długu technologicznego. Prawdą jest, że często tworzymy coś szybko, wydawać by się mogło sensownie… Jednak ze względu na różne czynniki zaciągamy coraz większy dług technologiczny. W pracy projektowej nie warto iść na skróty. Pośpiech i zaniedbanie to najczęstsze przyczyny nawarstwiania się długu technologicznego w projekcie.

Pół biedy, jeśli zaciągamy dług, który potrafimy później „spłacić”, czyli w odpowiednim czasie dokonać poprawek. Gorzej, jeśli zaciągamy dług przekraczający nasze umiejętności lub wychodzący poza ramy czasowe projektu. Niemożliwy do spłacenia dług technologiczny doprowadzić może do czegoś, co wszyscy dobrze znamy. Idealnie obrazuje to grafika poniżej.

Aby uniknąć tego problemu, warto użyć jednego z wielu dostępnych wzorców tworzenia architektury projektowej. Moim faworytem, a zarazem najczęściej używanym przeze mnie podejściem, jest Clean Architecture.

Czym jest Clean Architecture

Clean Architecture to podejście do programowania aplikacji, które zakłada wydzielenie czterech głównych modułów funkcjonalnych w projekcie. Moduły te to:

• Application,
• Presentation,
• Domain,
• Data.

W dalszej części omówię szczegółowo każdą z nich. Na początek kilka słów o głównej idei podejścia Clean Architecture.

Idea Clean Architecture

Robert C. Martin (Uncle Bob) w książce „Clean Architecture” definiuje cel architektury jako wspieranie cyklu życia systemu. Dalej za autorem: dobra architektura sprawia, że ​​system jest łatwy do zrozumienia, łatwy w rozwoju, łatwy w utrzymaniu i łatwy do wdrożenia. Ostatecznym celem jest zminimalizowanie kosztów eksploatacji systemu i maksymalizacja produktywności programistów.

Tworząc podejście Clean Architecture Robert C. Martin, dążył do stworzenia struktury projektu z wyraźnie oddzieloną odpowiedzialnością poszczególnych warstw. Założenie było następujące: każda z warstw ma wykonywać jedno zadanie i ma być łatwa do wyizolowania od reszty. Inne założenie to możliwość współdzielenia jednego kodu między wieloma środowiskami. Miałoby się to odbywać poprzez wyciągnięcie dwóch głównych modułów niezależnych od technologii użytej do tworzenia aplikacji: Presentation oraz Domain i współdzielenie w innych środowiskach, dopisując jedynie warstwy Application oraz Data. Warstwy te są ściśle powiązane ze środowiskiem, na którym uruchamiamy projekt. Dobrym przykładem może być napisanie logiki biznesowej raz i współdzielenie jej przez aplikacje mobilne na iOS i Android, ale również przez aplikacje webowe i desktopowe.

Clean Architecture – wzorce projektowe

Moduł prezentacji może zostać zaimplementowany za pomocą wielu popularnych wzorców projektowych: Model View ViewModel (MVVM), Model View Presenter (MVP), Model View Intent (MVI), Model View Controller (MVC) czy też wiele innych. Każdy programista ma własne preferencje, jeśli chodzi o wybór wzorca. Mimo iż każdy z nich ma wady i zalety, na potrzeby opisu tej architektury skupimy się na podejściu MVP. Jest to podejście, które osobiście preferuję.

Application

Warstwa aplikacji jest najmocniej połączona z technologią, w której używamy podejścia Clean Architecture. Zapewnia ona całą wizualną część projektu oraz reaguje na zadania powierzane jej przez warstwę prezentacji. Warstwa ta decyduje, w jaki sposób wyświetlane będą dane dostarczane przez część prezentacyjną. Zawiera ona logikę wyświetlania oraz informuje warstwę prezentacji o wszelkich akcjach wykonanych przez użytkownika. Obsługuje ona też mechanizm utrzymywania stanu Presentera oraz przygotowuje wszelkie niezbędne zależności do jego poprawnego działania.

Presentation

Presenter steruje całą aplikacją, jak i poszczególnymi ekranami, reaguje on również na poszczególne akcje wykonane przez użytkownika w części wizualnej. To również tu zapada decyzja, w jaki sposób obsłużyć dane zadania czy też jaką część aplikacji kolejno pokazać użytkownikowi. UseCase’y, opisane dalej, są jedynym sposobem komunikacji tego modułu z pozostałymi. Służy np. do wykonania logiki biznesowej lub też pobrania określonych danych. W podejściu MVP każdy Presenter ma interfejs do komunikacji z widokiem, komunikacja ta pozwala jedynie na zlecanie zadań widokowi, ale nie umożliwia ona żądania czegoś w zamian. Mówiąc prościej, Presenter wykonuje funkcje na interfejsie widoku, ale funkcje te nie mogą mieć typu zwracanego.

Domain

Domain to moduł zawierający całą logikę biznesową. Składa się on z wielu składowych:

UseCase

Najważniejsza, widoczna na zewnątrz składowa, wykorzystywana przez warstwę prezentacji. UseCase’y są odwzorowaniem realnych wymagań biznesowych i zapewniają logice prezentacji dostęp do operacji na danych (pobierania, zmiany, nasłuchiwania zmian). Umożliwiają również wykonywanie logiki biznesowej: obliczeń czy manipulacji na danych. Warto wspomnieć, iż są one jedyną możliwością komunikacji między warstwą prezentacji a warstwami domeny. Dane transportowane są przez modele przechowywane również w tej warstwie. UseCase’y dostęp do danych otrzymują za pośrednictwem DataSource’ów poprzez udostępniony przez nie interfejs. Innym rodzajem wykorzystywanych przez nie zależności są klasy z warstwy Logic opisane dalej.

Model

To zbiór w pewien logiczny sposób zebranych danych, wykorzystywanych przez logikę biznesową. Model ten nie musi być identyczny jak model z warstwy data. Może on np. łączyć kilka modeli data w zależności od potrzeb i zastosowania.

Logic

Miejsce w strukturze, które służy do przechowywania wydzielonych klas z rozbudowaną logiką biznesową. Miejsce te umożliwia unikanie rozbudowanych UseCase’ów.

DataSource

Najważniejszym zadaniem DataSource’ów jest decydowanie, skąd będą pobierane lub gdzie zapisywane będą dane. Właśnie one za pomocą interfejsów mają dostęp do wszystkich źródeł danych, które wystawia moduł Data. Oprócz danych w środku znajdziemy również Mappery umożliwiające tłumaczenie danych z warstwy Data na modele biznesowe wykorzystywane później. DataSource’y są jedynym połączeniem między modułem Data a resztą logiki biznesowej i to one wystawiają dalej interfejsy dające dostęp do dostosowanych danych dla UseCase’ów.

Mappery

Mappery w architekturze Clean Architecture dbają o spójność danych dostarczanych przez warstwę data. To właśnie tu odbywa się sprawdzenie, czy wszystkie niezbędne dane zostały dostarczone, tak aby logika biznesowa mogła w pełni działać. Mappery często łączą kilka obiektów z warstwy data z różnych źródeł, tworząc jeden, który ma wszystkie potrzebne dla logiki biznesowej dane.

Data

Moduł, który dostarcza dostęp do wszelkiego typu źródeł danych oraz modeli, które te dane odwzorowują. Dostęp do metod udostępnianych przez ten moduł możliwy jest jedynie dzięki wykorzystaniu interfejsów, które ten moduł udostępnia. Jest on również drugim modułem mającym największą zależność od platformy, na której wykorzystywana jest Clean Architecture.

Data transfer object

Data transfer object (w skrócie DTO) jest to model służący do dwustronnego przesyłania danych. Modele takie wykorzystywane są tylko w warstwie Data i w zależności od tego, czy dane te wysyłamy, czy też pobieramy, są one tłumaczone na modele biznesowe lub z nich za pomocą Mapperów.

Data

Data to miejsce pobierania i zapisywania danych wykorzystywanych w pozostałych częściach aplikacji. Przykładowe źródła danych to: Bluetooth, Internet, Shared Preferences, bazy danych, pliki, GPS, kamera, żyroskop czy system. Dostęp do takich danych odbywa się przez interfejs. Pozwala to na łatwe podmienianie danego źródła. Zamiana takiego źródła odbywa się poprzez podanie różnych obiektów implementujących ten interfejs. Zastępowanie źródeł danych najczęściej wykorzystywane jest np. do obsługi różnych typów serwerów czy też podpięcia mockowych danych.

Wady Clean Architecture

• Czasochłonność. Zaimplementowanie tak złożonej architektury wymaga dodatkowego czasu. Z mojego doświadczenia wynika, że pisanie kodu w podejściu Clean Architecture wymaga około 10% więcej czasu niż tworzenie aplikacji bez żadnej specjalnej architektury.
• Potrzebna jest wiedza. W ten typ podejścia wpisany jest utrudniony próg wejścia dla osób, które nie miały wcześniej wiedzy na temat tej struktury.
• Duża ilość małych klas i interfejsów. Jedni uważają to za wadę, inni z kolei za zaletę. Uczciwie będzie, gdy stwierdzimy, że w każdej opinii jest ziarno prawdy. Moja opinia jest taka, że to niewątpliwa zaleta – osoby mające inne zdanie uważają, że duża ilość plików jest trudna w zarządzaniu, a zmiany w nich poczynione – mało czytelne.

Zalety Clean Architecture

• Łatwiejsze utrzymanie. Clean Architecture znacząco ułatwia utrzymanie projektu. Naprawianie błędów w tym podejściu jest bardzo proste, a ich lokalizowanie – szybsze.
• Lepsze zarządzanie zmianą. Podejście przyśpiesza wprowadzanie zmian w projekcie. Dzięki małym klasom z wydzielonymi odpowiedzialnościami bardzo łatwo modyfikować kod pod kątem nowych wymagań czy też dodawać nowe funkcjonalności bez obawy o konsekwencje w pozostałych częściach projektu.
• Duża ilość małych klas i interfejsów. Jak już pisałem, tu zdania są podzielone. Ja uważam, że jest to zaleta z tego względu, że dzięki wielu małym klasom z wydzielonymi funkcjonalnościami kod daje się łatwo pokryć testami.

W jakich projektach stosować Clean Architecture?

Moim zdaniem Clean Architecture świetnie spełnia swoje zadanie w przypadku średnich i  dużych projektów. Złożoność podejścia w przypadku małych projektów może skutkować większym nakładem dodatkowych prac. Czy to znaczy jednak, że nie powinniśmy stosować wtedy Clean Architecture? Warto pamiętać, że małe projekty w naturalny sposób szybko się rozwijają. Podjęcie decyzji o stosowaniu podejścia CA nawet w mniejszych projektach jest moim zdaniem uzasadnione. Pozwala to uniknąć sytuacji zaciągania długu technologicznego, o którym pisałem. Szczególnie, gdy narzut czasowy jest nieduży.

Podsumowanie

Nawiązując do konceptu współdzielenia dwóch modułów między wieloma technologiami, uważam to za świetny pomysł i coraz bliższy realizacji. Do tej pory było to trudne w uzyskaniu, jednak dzięki upowszechnieniu języka programowania, jakim jest Kotlin już niedługo możemy mieć pierwsze projekty w pełni wykorzystujące te założenia. Mam nadzieję, że udało mi się przybliżyć główne założenia idei Clean Architecture i zachęcić do stosowania jej w projektach. Przemyślany wybór architektury pozwoli uniknąć długu technologicznego, a ten typ architektury – choć wymaga wiedzy i przeznaczenia więcej czasu na implementację, bez wątpienia sprawdza się długofalowo zarówno w większych, jak i mniejszych projektach.

Przeczytaj także:

• Test-Driven Development na co dzień
• Service mesh, ale komu to potrzebne?

1. 1. Observable oraz strumień danych
2. 2. Operatory w RxJS
3. 3. SwitchMap
4. 4. MergeMap
5. 5. ContactMap
6. 6. ExhaustMap
7. 7. FAQ

Observable oraz strumień danych

Jednymi z najważniejszych elementów biblioteki RxJS są Observable oraz strumienie danych.

Oba te pojęcia są podobne, jednak występują między nimi subtelne różnice:

Podsumowując, Observable mają szerszy zakres zastosowań niż strumienie danych i mają dodatkowe funkcje, pozwalające na kontrolowanie czasu przepływu wartości i sterowanie błędami.

Operatory w RxJS

Prawdziwą potęgę biblioteki RxJS stanowią operatory. Operatory pozwalają przekształcać, filtrować, łączyć strumienie danych i zarządzać nimi. RxJS dostarcza szereg operatorów, takich jak: map, filter, reduce, debounceTime, distinctUntilChanged itp., które pozwalają na przetwarzanie danych w strumieniach. Wybór odpowiedniego operatora jest ważny, gdyż źle dobrany operator może wpłynąć na funkcjonowanie systemu. Niżej omawiam najważniejsze z nich.

Przeczytaj także: Programowanie reaktywne w JavaScript z RxJS

Higher-Order Observable Mapping

Biblioteka RxJS zawiera szczególny typ operatorów, tzw. higher-order operators, czyli operatory wyższego rzędu, które pozwalają na złożone manipulowanie strumieniami danych. Higher-order operators to operatory, które zawierają w argumentach inne operatory lub Observable i zwracają nowe Observable mające zastosowanie do pierwotnego strumienia danych.

Istnienie higher-order operators w bibliotece RxJS jest uzasadnione z kilku powodów:

• Zapewniają one prostsze i bardziej czytelne sposoby manipulowania strumieniami danych. Dzięki nim można złożyć wiele operacji na strumieniu w jeden łańcuch, co ułatwia czytanie i zrozumienie kodu.
• Umożliwiają bardziej elastyczne manipulowanie strumieniami danych. Wiele higher-order operators pozwala na dynamiczne tworzenie nowych strumieni danych w zależności od zdarzeń zachodzących w pierwotnym strumieniu. Dzięki temu można łatwo dostosować przetwarzanie danych do zmieniających się wymagań.
• Higher-order operators pozwalają na wielokrotne wykorzystanie kodu. Wiele operacji na strumieniach danych jest podobnych i można je zastosować w wielu miejscach w aplikacji. Higher-order operators ułatwiają użycie tych samych operacji w różnych częściach kodu, co pozwala na uniknięcie powtórzeń.

Podsumowując, higher-order operators w bibliotece RxJS pozwalają na bardziej elastyczne, czytelne i wielokrotne wykorzystanie kodu do manipulowania strumieniami danych. Dzięki nim programiści mogą złożyć wiele operacji na strumieniu w jeden łańcuch, co ułatwia zarządzanie danymi w aplikacji.

RxJS udostępnia nam cztery operatory wyższego rzędu:

SwitchMap

Operator switchMap emituje wartości wewnętrznego Observable, ale każda nowa wartość emitowana przez strumień źródłowy powoduje anulowanie poprzedniego wewnętrznego Observable i utworzenie nowego. Wewnętrzny Observable zwrócony z funkcji mapującej jest zastępowany nowym wewnętrznym Observable, co oznacza, że jeśli źródłowy strumień emituje wartości z częstotliwością wyższą niż wewnętrzny Observable, operator switchMap przerywa działanie i zastępuje poprzedni wewnętrzny Observable. SwitchMap możemy zastosować w przypadku, gdy chcemy odwołać wcześniejsze żądania i wysłać tylko najnowsze żądanie, np. dotyczące filtrowania wyników wyszukiwania.

import { fromEvent } from 'rxjs'; 

import { switchMap } from 'rxjs/operators'; 

 

Pobieranie danych z serwera 

function fetchData(keyword: string) { 

  return fetch(`https://api.github.com/search/repositories?q=${keyword}`).then(res => res.json()); 

} 
 

Strumień wejściowy z danymi z pola tekstowego

const input$ = fromEvent(document.querySelector('input'), 'input'); 

Operator switchMap kończy subskrypcję poprzedniego strumienia i zwraca tylko strumień wyjściowy ostatniego wyemitowanego strumienia

const result$ = input$.pipe( 

  switchMap(event => fetchData(event.target.value)) 

); 

Subskrypcja strumienia wyjściowego

result$.subscribe( 

  data => console.log(data), 

  err => console.error(err), 

  () => console.log('Complete') 

); 

W tym przykładzie operator switchMap przekształca każdą wartość strumienia wejściowego (event z pola tekstowego) na strumień wyjściowy, który pobiera dane z serwera GitHub API na podstawie frazy wyszukiwania. Dzięki temu, kiedy użytkownik wprowadza nową frazę, operator switchMap anuluje subskrypcję poprzedniego strumienia wyjściowego i zwraca tylko wynik dla ostatniej frazy.

MergeMap

Operator mergeMap przetwarza wszystkie wartości w strumieniu źródłowym jednocześnie, emitując wartości wewnętrzne Observable. Operator tworzy wiele wewnętrznych Observables, co oznacza, że wynikowy strumień wyjściowy może emitować wartości w dowolnej kolejności. Przykładowym zastosowaniem operatora mergeMap może być równoległe pobieranie danych z wielu źródeł.

Operator mergeMap jest szczególnie przydatny w sytuacjach, gdy potrzebujemy wykonać operację asynchroniczną dla każdego elementu strumienia wejściowego i uzyskać strumień wyjściowy składający się z wyników tych operacji.

import { from, Observable } from 'rxjs'; 

import { mergeMap } from 'rxjs/operators'; 

Definicja funkcji zwracającej strumień asynchroniczny

function makeHttpRequest(id: number): Observable {

return fetch(https://jsonplaceholder.typicode.com/posts/${id}).then(res => res.json());

}

Strumień wejściowy z listą identyfikatorów

const ids$ = from([1, 2, 3, 4, 5]); 

 

Operator mergeMap przekształca każdy element strumienia wejściowego na strumień wyjściowy

const posts$ = ids$.pipe( 

  mergeMap(id => makeHttpRequest(id)) 

); 

Subskrypcja strumienia wyjściowego

posts$.subscribe( 

  post => console.log(post), 

  err => console.error(err), 

  () => console.log('Complete') 

); 

W tym przykładzie operator mergeMap przekształca każdy element strumienia wejściowego (identyfikator posta) na strumień wyjściowy reprezentujący wynik asynchronicznej operacji pobierania danych z serwera dla danego posta. W efekcie otrzymujemy strumień wyjściowy składający się z pobranych postów, a nie z identyfikatorów.

ContactMap

Operator concatMap emituje wartości wewnętrznego Observable w kolejności, w jakiej są one dostarczane. Operator nie tworzy wielu wewnętrznych Observables, dopóki poprzedni Observable nie zakończy działania. W przypadku, gdy w strumieniu źródłowym pojawi się kolejna wartość, zanim zakończy działanie poprzedni wewnętrzny Observable. Operator concatMap umieszcza wartości kolejnego wewnętrznego Observable w kolejce i przetwarza je dopiero po zakończeniu poprzedniego Observable.

import { of } from 'rxjs'; 

import { concatMap, delay } from 'rxjs/operators'; 

Strumień wejściowy z liczbami

const source$ = of(1, 2, 3, 4, 5); 

Operator concatMap przekształca każdy element strumienia wejściowego na nowy strumień wyjściowy z opóźnieniem w zależności od wartości elementu

const example$ = source$.pipe( 

  concatMap(value => of(`Delayed by: ${value * 1000}ms`).pipe(delay(value * 1000))) 

); 

Subskrypcja strumienia wyjściowego

example$.subscribe(console.log); 

W powyższym przykładzie concatMap przekształca każdą wartość strumienia wejściowego (1, 2, 3, 4, 5) na strumień wyjściowy, który zostaje opóźniony o wartość elementu w sekundach i zwrócony w kolejności ich pojawiania się w źródłowym strumieniu. Dzięki temu pierwszy element (1) zostanie zwrócony po jednej sekundzie, drugi element (2) po dwóch sekundach itd.

ExhaustMap

Operator exhaustMap przekształca każdy element strumienia wejściowego (źródłowego) na nowy strumień i ignoruje wszystkie kolejne elementy, zanim zakończy działanie strumień wyjściowy.

ExhaustMap jest przydatny, gdy jest nam potrzebne, żeby w danym czasie był emitowany tylko jeden strumień wyjściowy. W przypadku, gdy pojawiają się nowe elementy w strumieniu wejściowym przed zakończeniem strumienia wyjściowego, są one ignorowane aż do zakończenia działania poprzedniego strumienia wyjściowego.

Przykładowym zastosowaniem operatora exhaustMap może być ograniczenie liczby żądań sieciowych w sytuacji, gdy w aplikacji użytkownik kliknie wiele razy na przycisk, ale zwrócone zostanie tylko jedno zapytanie.

 

import { interval } from 'rxjs'; 

import { exhaustMap, take } from 'rxjs/operators'; 

Strumień wejściowy z wartościami

const source$ = interval(1000).pipe(take(4)); 

Operator exhaustMap przekształca każdą wartość strumienia wejściowego na nowy strumień wyjściowy, który zostaje zwrócony dopiero po zakończeniu działania jego poprzednika. 

const example$ = source$.pipe( 

  exhaustMap(value => interval(500).pipe(take(3))) 

); 

Subskrypcja strumienia wyjściowego 

example$.subscribe(console.log); 

Powyższy przykład obrazuje sytuacje, gdy operator exhaustMap przekształca każdą wartość strumienia wejściowego (0, 1, 2, 3) na strumień wyjściowy emitujący wartości z opóźnieniem 0,5 sekundy. Każdy kolejny strumień wyjściowy zostanie zignorowany, dopóki poprzedni nie zostanie zakończony, dlatego drugi strumień wyjściowy z wartościami (0, 1, 2) nie zostanie wyemitowany, ponieważ pierwszy strumień z wartościami (0, 1, 2) nadal jest w trakcie emisji.

Podsumowując:

• exhaustMap ignoruje nowe zdarzenia, jeśli obecny strumień wciąż trwa. Jeśli w trakcie trwania strumienia wejściowego operator otrzyma kolejne zdarzenie, to zostanie ono pominięte, aż do momentu, gdy strumień wejściowy się zakończy.
• mergeMap przetwarza wszystkie wartości w strumieniu źródłowym jednocześnie, emitując wartości wewnętrznych Observables.
• concatMap emituje wartości wewnętrznego Observable w kolejności, w jakiej są one emitowane.
• switchMap emituje wartości wewnętrznego Observable, ale zastępuje poprzedni wewnętrzny Observable nowym, gdy źródłowy strumień emituje nowe wartości.

FAQ:  

Przejdź do:

1. 1. Wyzwania współczesnych aplikacji internetowych
2. 2. Czym jest programowanie reaktywne?
3. 3. Strumienie danych
4. 4. Co to jest observable?
5. 5. Observable vs promise w JavaScript
6. 6. Hot vs cold observables
7. 7. Tworzenie observable
8. 8. Subskrybcje
9. 9. Observer
10. 10. RxJS – zalety
11. 11. RxJS – wady
12. 12. Podsumowanie

Wyzwania współczesnych aplikacji internetowych

Tworząc nowoczesne i wydajne aplikacje internetowe, mierzymy się z wieloma wyzwaniami, o czym wspominał m.in. Paweł Adamowicz w swoim materiale Zarządzanie stanem aplikacji frontendowej za pomocą NgRx. Jako programiści powinniśmy między innymi brać pod uwagę to, że nie można blokować użytkownika i kazać mu czekać, aż nasza witryna obsłuży kilka zdarzeń. Co zatem zrobić w momencie, kiedy aplikacja jednocześnie musi uruchomić animację, załadować loader czy zareagować na działanie użytkownika? Jak obsłużyć te wszystkie sytuacje naraz? Tutaj z pomocą przychodzi nam paradygmat programowania reaktywnego wraz z biblioteką RxJS.

Czym jest programowanie reaktywne?

Programowanie reaktywne to paradygmat służący do pisania kodu opierającego się na asynchronicznych strumieniach danych.

Jest to sposób tworzenia aplikacji, które reagują na zachodzące zmiany, w przeciwieństwie do typowego, imperatywnego sposobu pisania oprogramowania, w którym jawnie tworzymy instrukcję krok po kroku, aby te zmiany obsłużyć.

Brzmi to dość skomplikowanie i faktycznie takie podejście wymaga zmiany sposobu myślenia. Jednak istnieją rozwiązania, które zdecydowanie ułatwią zmianę podejścia na reaktywne – w przypadku JavaScript jest nim właśnie biblioteka RxJS.

Strumienie danych

Strumień to sekwencja danych uporządkowanych w czasie. Strumienie danych mogą być tworzone z obiektów, zmiennych, struktur danych, za pomocą zdarzeń (kliknięć), odpowiedzi żądań HTTP itd.

Na swojej osi czasu strumień może również emitować error (gdy wystąpi nieoczekiwane zdarzenie powodujące zakończenie strumienia) lub status completed, gdy strumień wyemitował wszystkie dane. Możemy przechwycić te metody (error i complete) i wykonać na nich odpowiednie dla nas operacje, o czym więcej piszę w dalszej części.

Przeczytaj także: Angular – zróbmy swoją PWA.

Co to jest observable?

RxJS udostępnia nam obiekt observable, który wykorzystuje wzorzec projektowy – obserwator.

Możemy to zilustrować na przykładzie subskrybcji do newslettera. Zapewne nieraz zdarzyło ci się kliknąć przycisk „subskrybuj”, czy to na YouTube, czy np. jakimś blogu. W momencie kiedy pojawi się nowy artykuł lub inny materiał, dostajesz od razu powiadomienie o pojawieniu się nowych zasobów. W każdym momencie możesz także zrezygnować z subskrypcji.

Tak samo działają observable i strumienie.

• Klikając przycisk subscribe, stajesz się obserwatorem danych zasobów,
• observable jako obiekt obserwowany serwuje nam strumień danych z nowościami,
• subskrypcja do strumienia zapewnia nam metodę „subscribe”,
• możemy również wybrać, które dane są dla nas wartościowe jako nowości.

Observable vs promise w JavaScript

Observable to nic innego jak strumień z wartościami (absolutnie dowolnego typu). Ale zaraz, zaraz… Po co nam ten cały observable, skoro mamy już promise w JavaScript? Observable daje nam dużo większe możliwości, poniżej krótkie porównanie:

Promise

• za każdym razem jest asynchroniczny, 
• jest „eager” – przetwarzanie rozpoczyna się natychmiastowo po jego zdefiniowaniu, 
• może zwracać tylko jedną wartość, 
• nie posiada operatorów, 
• nie może być anulowany.

Observable

• może być zarówno synchroniczny, jak i asynchroniczny,
• jest „lazy” – będzie wykonany nie w momencie zdefiniowania strumienia, ale w momencie, w którym utworzona zostanie subskrypcja,
• zwraca jedną lub wiele wartości,
• do dyspozycji mamy całą gamę operatorów,
• możemy go anulować w dowolnym momencie,
• daje nam więcej możliwości przy obsłudze błędów (m.in. operator retry()).

Hot vs cold observables

Observable dzielimy na hot i cold.

Cold observables:

• emitowanie wartości zaczyna się w momencie pojawienia się pierwszego subskrybenta (gdy pojawi się pierwszy subscribe() – o tym w dalszej części artykułu),
• dla każdego nowego subskrybenta zwracają nowe wartości,
• przykładem może być np. serwis do pobierania danych z backendu, gdzie żeby wykonać zapytanie, musimy użyć subscribe.

Hot observables:

• wysyłają wartości pomimo braku subskrybenta,
• dzielą te same dane pomiędzy wszystkich subskrybentów,
• przykład: observable stworzony z eventu click.

Tworzenie observable

Istnieje wiele sposobów na stworzenie observable. Często spotykamy się z tworzeniem ich z innych struktur danych – tutaj z pomocą przychodzą nam operatory of lub from. Dla RxJS nie jest również problemem stworzenie jednego observable z kilku innych. Poniżej kilka przykładów.

Operator from przyjmuje tylko jeden argument, po którym można iterować (np. tablice, elementy tablicopodobne, weźmy za przykład tablicę obiektów).

 

import { from, Observable } from 'rxjs'; 

  

const to ReadBooks = [  

{  bookId: 1, title: The psychology of money', author: 'Morgan Housel' 

publicationYear: 2020 }, 

{  bookId: 2, title: 'The subtle art of not giving a f*ck', author: 'Mark Manson', 			publicationYear: 2016 }, 

{ bookId: 3, title: How to talk to anyone', author: 'Leil Lowndes', publicationYear: 1999 }, 

{ bookId: 3, title: 'Invent and wander', author: Jeff Bezos', publicationYear: 2020 }, 

  

];  

  

let source2$ = from(toReadBooks); 

source2$.subscribe(book => console.log(book.title)); 

W ten sposób nasza tablica obiektów zamieniła się w observable. Proste, prawda?

A co w sytuacji, gdy mamy kilka strumieni, a potrzebujemy jednego observable? Żaden problem! RxJS udostępnia kilka operatorów, które nam w tym pomogą. Jednym z nich jest concat.

import { concat, from, Observable, of } from 'rxjs'; 

  

const toReadBooks = [ 

  

  

{  bookId: 1, title: The psychology of money', author: 'Morgan Housel'  

publicationYear: 2020 },  

{  bookId: 2, title: 'The subtle art of not giving a f*ck', author: 'Mark Manson', 			publicationYear: 2016 },  

{ bookId: 3, title: How to talk to anyone', author: 'Leil Lowndes', publicationYear: 1999 },  

{ bookId: 3, title: 'Invent and wander', author: Jeff Bezos', publicationYear: 2020 }, 

  

];  

  

let source1$ = of('hello', 10, true, toReadBooks[0].title); 

source1$.subscribe(value => console.log(value)); 

  

let source2$ = from(toReadBooks); 

source2$.subscribe(book => console.log(book.title)); 

  

// combine the 2 sources  

concat(source1$, source2$) 

.subscribe(value => console.log(value)); 

Voilà! RxJS naprawdę ułatwia życie!

Subskrybcje

Powyżej wspomniałem o możliwości subskrypcji do strumienia. Kolejny termin, który brzmi skomplikowanie (ale wcale taki skomplikowany nie jest!). Subskrybcja to po prostu podłączenie się do strumienia. Każdy observable posiada metodę subscribe(), do której możemy przekazać parametry na dwa sposoby: jako obiekt z metodami lub jako zestaw callbacków. Obiekt przekazany do metody subscribe nazywamy observerem.

Observer

Observer posiada trzy składowe:

• pierwsza metoda (next) jest wykonana, jeśli uda nam się odebrać wartość ze strumienia. Każda nowa wartość powoduje wywołanie tej metody,
• druga metoda (error) jest wykonana, jeśli w strumieniu wystąpi błąd, na przykład w zapytaniu HTTP dostaniemy status 500. W przypadku wystąpienia błędu nasz observer nie przejdzie dalej i nie wykona metody complete, a tym samym zostanie zaznaczony jako closed i przestanie emitować wartości,
• trzecia metoda (complete) jest wykonana w momencie, gdy strumień wyemituje ostatnią wartość.

RxJS – zalety

Biblioteka RxJS niewątpliwie ułatwia rozwój aplikacji. Możemy ją zintegrować właściwie z dowolnym frontendowym frameworkiem (Angular, React). Również użycie z czystym JavaScriptem nie stanowi problemu. Do dyspozycji mamy ogromną liczbę operatorów, które pozwalają nam na dowolną modyfikację naszych strumieni. Stale pojawiające się aktualizacje sprawiają, że kolejne wydania biblioteki są coraz prostsze w użyciu. Dzięki RxJS zdecydowanie możemy przyspieszyć naszą pracę, jak również poprawić jakość wytwarzanego oprogramowania.

RxJS – wady

Tutaj zdecydowanie trudniej jest mi coś napisać niż w przypadku zalet. Pracując na co dzień z Angularem, nie wyobrażam sobie napisania choćby jednego komponentu bez użycia biblioteki RxJS. Na pewno rzeczą, która sprawia trudność – zwłaszcza początkującym programistom – jest testowanie kodu wykorzystującego RxJS. Testowanie takiego kodu wymaga znajomości wielu dodatkowych technik oraz narzędzi. Na szczęście RxJS ma na to swoje rozwiązanie i tu z pomocą przychodzi nam RxJS Marbles (umożliwia testowanie asynchronicznego kodu RxJS synchronicznie i krok po kroku za pomocą narzędzia testowego RxJS TestScheduler oraz przy użyciu wirtualnych kroków czasowych), jednak jest to dość obszerny temat, któremu można by poświęcić nowy wpis.

Podsumowanie

Powyższe informacje stanowią bardzo ogólny opis programowania reaktywnego oraz biblioteki RxJS. O każdym z powyższych tematów śmiało mógłby powstać oddzielny artykuł, a mój to zaledwie kropla w morzu – wiele aspektów zostało pominiętych.

Jednak bez dwóch zdań używanie RxJS stało się standardem w tworzeniu nowoczesnych i wydajnych aplikacji. Ciągły rozwój i wsparcie dla najpopularniejszych frameworków sprawia, że RxJS jest zdecydowanie najczęściej używaną biblioteką ułatwiającą zapanowanie nad asynchronicznością.

Idź do:

1. 1. Mikroserwisy – ich popularność rośnie
2. 2. Jak architektura mikroserwisów odpowiada dziś na potrzeby rozwoju systemów?
3. 3. Bolączki monolitycznej aplikacji
4. 4. Zalety wykorzystania architektury mikroserwisów
5. 5. Wady mikroserwisów
6. 6. Mikrousługi a podejście DDD
7. 7. Mikroserwisy w praktyce – case study
8. 8. Podsumowując: czy architektura mikroserwisowa sprawdzi się w moim projekcie?

Mikroserwisy – ich popularność rośnie

Pojęcie architektury mikroserwisowej pojawiło się po raz pierwszy na scenie IT w okolicach roku 2013. Od tego czasu jej popularność wydaje się poruszać tylko w jednym kierunku – w górę! Potwierdzenie takiej hipotezy możemy znaleźć na przykład w raporcie „Microservices adoption” przygotowanym przez firmę O’Reilly w roku 2020, z którego wynika, że 77% firm, w których pracują respondenci, stosują taką architekturę. Jednocześnie aż 92% pytanych określiło zastosowanie mikroserwisów jako sukces  z perspektywy oczekiwanych zysków, które przynosi takie podejście.

W innej ankiecie przeprowadzonej przez IBM Market Development & Insights o opinię zapytanych zostało ponad 1200 osób z branży IT, w tym dyrektorzy techniczni, menedżerowie i programiści pracujący w firmach, które stosują lub planują zastosować architekturę mikroserwisową.

Wyniki są jednoznaczne:

• 87% użytkowników zgadza się, że wysiłek oraz koszty poniesione na wdrożenie architektury mikroserwisowej opłacały się.
• 84% użytkowników zgadza się, że stosowanie mikroserwisów ułatwia pracę obecnym pracownikom oraz pozwala na przyciągnięcie nowych.
• 77% użytkowników zgadza się, że mikroserwisy są sprawdzonym i niezawodnym modelem tworzenia aplikacji.

Chociaż jest to oczywiście bardzo wątpliwa miara, z własnej perspektywy programisty – sądząc po opisach projektów w ofertach pracy – mógłbym stwierdzić, że praktycznie większość projektów jest aktualnie tworzona w architekturze mikroserwisowej. Pomimo że na takie opisy musimy spojrzeć z przymrużeniem oka, widać, że mikroserwisy szybko stają się standardem w świecie IT.

Jak architektura mikroserwisów odpowiada dziś na potrzeby rozwoju systemów?

Jednym z największych wyzwań architektury mikroserwisowej jest silna zależność od infrastruktury (serwerowej, sieciowej itp.), a co za tym idzie – zwiększona potrzeba inwestycji w jej tworzenie. Jeszcze kilka lat temu było to jednak dużo większym wyzwaniem niż dzisiaj. W odpowiedzi na potrzeby nowego modelu powstał szeroki wachlarz narzędzi, które usprawniają pracę w rozproszonym środowisku.

• Kontenery – na potrzeby orkiestracji serwisami powstały rozwiązania do zarządzania, automatyzacji i skalowania aplikacji kontenerowych. Dzisiaj możemy wybierać spośród wielu narzędzi, od prostych i niewymagających, jak Docker Swarm, po zakrojone na największą skalę rozwiązania enterprise, jak chyba najpopularniejszy Kubernetes lub Openshift. Dodatkowo dostępne są rozwiązania chmurowe, jak AWS Fargate czy Google Cloud Run. Każda z platform chmurowych oferuje również zarządzane przez siebie serwisy Kubernetes, jak AWS EKS lub Google GKE. Wszystkie wymienione narzędzia w znacznym stopniu zmniejszają dzisiaj próg wejścia do projektów opartych na mikroserwisach pod względem infrastruktury serwerowej. Należy jednak liczyć się z kosztami ich utrzymywania.
• Service Mesh – w odpowiedzi na wyzwania związane z silną zależnością od infrastruktury sieciowej powstało wiele rozwiązań, z których najpopularniejszy jest obecnie model Service Mesh. Tutaj znowu mamy wybór pomiędzy lekkimi rozwiązaniami jak Linkerd, Kuma czy Maesh a bardziej wymagającymi, jak Istio, oraz rozwiązaniami chmurowymi, jak AWS App Mesh. Jak widać, stworzenie infrastruktury sieciowej dla swojej aplikacji mikroserwisowej nie stanowi dzisiaj tak dużego wyzwania jak kiedyś, chociaż sama zależność od sieci jest i zawsze pozostanie wyzwaniem.
• Narzędzia do monitorowania – cytując głównego inżyniera firmy Lyft, Matta Kleina, który brał udział w przejściu firmy z monolitu na mikroserwisy:

Inną istotną zmianą, która pojawia się wraz z rozwojem mikroserwisów, jest obecność sieci jako niestabilnego elementu, którego nie da się uniknąć. Każdy programista musi w końcu poradzić sobie z problemami sieciowymi, zarówno jeśli chodzi o transport, jak i o znacznie bardziej złożone narzędzia wymagane do debugowania.

Wspomniane wyżej narzędzia wspierające pracę i debugowanie aplikacji kontenerowej również przeżyły rozkwit i dzisiaj możemy wspierać się narzędziami do monitorowania, logowania i tracingu. Rozwiązania takie jak Prometheus, ELK czy AWS CloudWatch pozwalają sprostać wyzwaniom utrzymywania lub debugowania aplikacji w rozproszonym środowisku.

Bolączki monolitycznej aplikacji

Powstanie i ostateczny sukces mikroserwisów nie wziął się oczywiście z niczego. Jest to raczej odpowiedź na trudności związane z klasycznym podejściem, które w wielu przypadkach przeważają nad plusami podejścia monolitycznego.

Z perspektywy biznesu i użytkowników

Z perspektywy biznesowej możemy wymienić wiele wad, które mogą wpłynąć na doświadczenia użytkowników i tym samym – na ostateczny sukces aplikacji:

• Wprowadzanie nawet najmniejszej zmiany wymaga reinstalacji całej aplikacji, co prowadzi do tymczasowej niedostępności aplikacji, która w nowoczesnym świecie jest praktycznie niedopuszczalna dla komercyjnych rozwiązań.
• Poszczególne komponenty systemu są ze sobą ściśle powiązane, co oznacza, że nawet mała zmiana w kodzie może negatywnie wpłynąć na całą aplikację, a tym samym być odczuwalna dla 100% jej użytkowników.
• Trudności nastręcza skalowanie aplikacji w odpowiedzi na zmienny ruch. Niemożliwe jest też oczywiście skalowanie poszczególnych komponentów systemu, a tylko całej aplikacji. W momencie przeciążenia aplikacja może stać się niedostępna dla części użytkowników.
• Brak skalowalności może się przekładać na wyższe koszty utrzymania aplikacji.
• Spowolnienie prędkości rozwoju i udostępniania nowej funkcjonalności.
• Zdecydowanie zmniejszona możliwość zastosowania nowych technologii, których wprowadzenie byłoby zbyt kosztowne i wymagałoby poświęcenia więcej czasu przez programistów (czy nawet zatrudnienia nowych).

Z perspektywy developera

Patrząc z perspektywy developera pracującego nad monolitem, możemy dodatkowo wymienić jeszcze kilka wad:

• Spora baza kodu jest trudna w zrozumieniu, co od nowego programisty wymaga dużo czasu na poznanie i wdrożenie. Spowalnia ona również codzienny cykl wprowadzania zmian i ich testowania (pamiętajmy, że każda, nawet drobna zmiana, może mieć wpływ na całą aplikację).
• Rozmyta odpowiedzialność oraz brak poczucia własności kodu może wpływać demotywująco na programistę. W przeciwieństwie do całkowitej własności części systemu, którego czujemy się autorem w przypadku tworzenia i utrzymywania konkretnych mikrousług.
• Trudność we wdrożeniu nowych, interesujących technologii, ponieważ każda taka inicjatywa oznacza wprowadzenie zmian w całej bazie kodu aplikacji.
• Mniejsze możliwości rozwoju osobistego – w dynamicznie zmieniającym się świecie IT rozważne jest, aby developer ciągle się rozwijał i zawsze dysponował aktualną wiedzą. Praca nad aplikacją monolityczną może nie być najlepszym krokiem, gdyż nie ma się styczności z szeroką wiedzą wymaganą w świecie mikroserwisów.

Zalety wykorzystania architektury mikroserwisów

Przejdźmy teraz do możliwości i udogodnień dostępnych przy wykorzystaniu mikroserwisów.

Z perspektywy biznesu i użytkowników

• Łatwa redundancja elementów (czyli duplikowanie poszczególnych komponentów celem zapewnienia ciągłości pracy w razie awarii) i ich skalowanie, zgodnie z aktualnym zapotrzebowaniem, a tym samym większa dostępność systemu. Maleje tym samym ryzyko, że użytkownik nie będzie mógł skorzystać z naszej aplikacji.
• Luźne powiązanie poszczególnych serwisów pozwala na niezależny rozwój funkcjonalności i szybsze ich wdrożenie.
• Wdrożenia mogą następować niezależnie od siebie i praktycznie nie wpływają na dostępność całości systemu dla użytkowników.
• Mikroserwisy są idealnie dostosowane do wykorzystania architektury typu serverless, która w odpowiednich zastosowaniach pozwoli zaoszczędzić na kosztach infrastruktury.
• Łatwiejsze testowanie małych komponentów pozwala na uniknięcie wystąpienia uciążliwych dla użytkowników bugów.
• Wdrożenie nowych technologii, z korzyścią dla użytkownika, jest zdecydowanie łatwiejsze i może odbywać się na poziomie poszczególnych serwisów.

Z perspektywy developerów

Z zastosowaniem mikroserwisów łączy się też kilka pozytywów dla pracujących z nimi developerów:

• Pojedyncze usługi są łatwiejsze w zrozumieniu, ich baza kodu jest też odpowiednio mniejsza. Ułatwia to pracę nad nowymi funkcjonalnościami i ich testowaniem, ale również usprawnia wdrożenie nowej osoby w projekt.
• Każdy z twórców danej usługi czuje się za nią odpowiedzialny i dobrze zna domenę biznesową powierzonej mu części.
• Możliwość eksperymentowania i poszerzania wiedzy o nowych technologiach przy tworzeniu nowych funkcjonalności.
• Mniejsza koncentracja wiedzy wśród programistów, co pozwala uniknąć sytuacji, w której brak kluczowej osoby może okazać się poważnym problemem.
• Odpowiedzialność za poszczególne komponenty jest podzielona pomiędzy oddzielne zespoły, co pozwala na skuteczne dyżurowanie i szybką reakcję odpowiednich dla danego problemu osób.

Przeczytaj także: Mikroserwisy – Service Mesh z Istio. Poznaj Istio i możliwości jakie daje.

Wady mikroserwisów

Z perspektywy biznesu

• Początkowy koszt wykonania aplikacji w architekturze rozproszonej może być wyższy niż w przypadku monolitu. Podwyższony koszt to przede wszystkim wydatek na infrastrukturę oraz zaangażowanie odpowiednich specjalistów DevOps, odpowiedzialnych za jej utrzymanie.
• Ryzyko, że realizacja aplikacji będzie utrudniona lub nawet się nie powiedzie, jest większe z powodu nieodłącznej złożoności takiej architektury.
• Wdrożenie takiej architektury wymaga zmiany podejścia całego zespołu pracującego nad aplikacją. Decyzyjność przesuwa się od menedżerów i architektów w stronę poszczególnych zespołów. Z taką autonomią przychodzi większa potrzeba skutecznej komunikacji i współpracy pomiędzy zespołami.

Z perspektywy developera

• Funkcjonalność wymagająca bezwzględnej spójności danych (transakcje bankowe itp.) jest trudniejsza do implementacji, ponieważ wymaga dodatkowej koordynacji całego procesu, który może być realizowany w kliku usługach. W aplikacji monolitycznej taki problem byłby rozwiązany za pomocą transakcji na poziomie bazy danych.
• Debugowanie może być utrudnione z powodu rozproszenia logiki w wielu usługach, których logi mogą zawierać wskazówki o błędzie. Dodatkowymi źródłami błędów mogą okazać się punkty komunikacji pomiędzy poszczególnymi usługami.
• Testowanie integracyjne nowych funkcjonalności staje się bardziej skomplikowane, ponieważ nie ma możliwości przetestowania całego systemu rozproszonego.

Mikrousługi a podejście DDD

Większość korzyści płynących z zastosowania architektury rozproszonej jest efektem stworzenia prawidłowego podziału odpowiedzialności poszczególnych usług i wyznaczenia sposobu komunikacji między nimi. Celem jest stworzenie silnej spójności serwisów i jednocześnie luźnego powiązania pomiędzy nimi. Innymi słowy, rzeczy, które zwykle wymagają wspólnej zmiany, powinny należeć do jednego serwisu. Bez odpowiedniego podziału zamiast korzyści, jak niezależna implementacja czy skalowalność usług, możemy skończyć z niewydajnym lub trudnym w utrzymaniu projektem. W praktyce jest to oczywiście trudniejsze do zrealizowania niż w teorii – wstępne założenia lub późniejsze wymagania ulegają zmianie. Z tego powodu możliwość łatwego wprowadzania zmian jest kolejnym krytycznym aspektem podczas projektowania każdej aplikacji.

Podejście Domain-driven design (DDD) jest kluczowym narzędziem podczas projektowania architektury mikroserwisowej, tak przy rozbijaniu aplikacji monolitycznej, jak i tworzeniu aplikacji od zera.

Czym jest DDD? Czyli jak okiełznać system podczas tworzenia oprogramowania

DDD zapoczątkowane w książce Erica Evansa to zestaw zasad i wzorców, których celem jest wsparcie tworzenia aplikacji rozproszonych w oparciu o model domeny biznesowej będącej tematem tworzonego oprogramowania. Zespół programistów wraz z ekspertami domeny biznesowej tworzą model biznesowy w wypracowanym wspólnym języku, tzw. ubiquitous language. Następnie stworzony model jest tłumaczony na poszczególne usługi, ustalane są protokoły komunikacji między nimi oraz tworzone są zespoły odpowiedzialne za poszczególne serwisy. W całym procesie  pomocny może być dodatkowo event storming. Wzorce DDD mają na celu ułatwienie zrozumienia domeny i zależności w niej zachodzących. Od tego już niedaleko do wyznaczenia granic w domenie, a tym samym wypracowania podziału na usługi zmapowane na domenę biznesową.

Mikroserwisy w praktyce – case study

W istniejącej od wielu lat platformie e-commerce pojawiło się nowe wymaganie biznesowe, polegające na masowym tworzeniu nowych ofert na bazie plików. Narzędzie miało być głównie stosowane przez sprzedawców oferujących szeroki asortyment, którzy w ten sposób mogliby usprawnić i zautomatyzować interakcję z platformą w kwestii tworzenia i edycji swoich ofert.

Wspomniana platforma, chociaż została stworzona jako monolit, od dawna jest już rozbita i rozwijana w architekturze mikroserwisowej. Zadanie zlecone jednemu z zespołów Inetum polegało więc na stworzeniu nowej mikrousługi (ostatecznie powstało ich kilka) odpowiedzialnej za realizację tej funkcjonalności. Prace nad rozwiązaniem postępowały bez ingerencji w resztę usług aplikacji, której rozwój mógł postępować niezależnie. Jedynym punktem styku z resztą platformy stała się inna mikrousługa, a szczegóły komunikacji i implementacji zostały ustalone pomiędzy zespołami odpowiedzialnymi za obie usługi. Również decyzje o wyborze technologii (jak baza danych czy nawet język programowania) pozostawały w dużej mierze w gestii zespołu. Po wdrożeniu na produkcję zespół Inetum jest w stanie dynamicznie skalować ilość instancji usługi adekwatnie do liczby zapytań od użytkowników.

Taka autonomia jest kluczowa przy rozwoju aplikacji, nad którą kolektywnie pracują nawet setki zespołów. Trudno sobie wręcz wyobrazić skuteczne wdrożenie takiej funkcjonalności, gdyby cala platforma była nadal monolitem.

Podsumowując: czy architektura mikroserwisowa sprawdzi się w moim projekcie?

Odpowiedź na to pytanie musi być niestety wymijająca – to zależy. Decydując się na dany model, akceptujemy kompromis, czyli przyjmujemy go razem z jego mocnymi i słabymi stronami.

Gdy chcemy rozbić monolit

Jeżeli rozważamy rozbicie istniejącej aplikacji monolitycznej, decyzja jest może prostsza, zmotywowana wszystkimi bolączkami, które nastręcza monolit. W tym przypadku jednym ze sprawdzonych podejść jest odcinanie mniejszych serwisów z głównego bloku, aż w końcu nowe funkcjonalności będą mogły być tworzone w całkowitej izolacji, a mniejszy centralny monolit będzie stopniowo wygaszany.

Gdy tworzymy aplikację od podstaw

Jeżeli jednak rozpoczynamy tworzenie aplikacji od zera, jednym z kluczowych względów, na którym możemy oprzeć decyzję, jest rozmiar docelowej aplikacji. W przypadku tworzenia MVP aplikacji, najważniejsza jest szybkość dostarczenia funkcjonalności kosztem innych priorytetów. Zgodnie z zasadą YAGNI (You Ain’t Gonna Need It) nie ma sensu inwestować w zastosowanie zbyt wyszukanych narzędzi, jeśli nie mamy pewności, że aplikacja będzie się cieszyć odpowiednim poziomem zainteresowania.

Taka sytuacja przemawia więc za zastosowaniem monolitu, który dopiero w dalszej fazie zostanie podzielony – ciekawym rozwiązaniem może być zastosowanie architektury tzw. modularnego monolitu, w której funkcjonalności rozbite są na poszczególne moduły tworzone w ramach jednej aplikacji.

Jeśli jednak wiemy, że rozmiary docelowej aplikacji uzasadniają wstępną inwestycję, wtedy architektura mikroserwisowa jest jak najbardziej rozsądnym wyborem.

Przeczytaj także: Kim jest DevOps i jak wspiera projekty IT?

Przejdź do:

1. 1. Czym jest Istio
2. 2. Co dostajemy prosto z pudełka
3. 3. Przykład użycia Istio – zarządzanie ruchem sieciowym
4. 4. Podsumowanie

Czym jest Istio

Istio jest implementacją koncepcji Service Mesh, projektem open-source, stworzonym przez zespół Google i IBM we współpracy z zespołem Envoy z firmy Lyft. Istio wykorzystuje sprawdzone proxy Envoya, aby zapewnić korzyści oferowane przez takie podejście do warstwy sieci w klastrze. Główne zalety to: dodanie podstawowej konfiguracji, która dostarcza połączenie sieciowe, oraz zabezpieczenie i monitorowanie istniejących serwisów bez zmian w kodzie istniejących aplikacji.

Kubernetes – Istio: jak to działa razem?

Istio w ekosystemie Kubernetesa dzieli się na dwa komponenty: data plane i control plane.

Data plane to kolektywna nazwa dla wszystkich proxy Envoy, przez które przechodzi komunikacja w klastrze. Proxy przechwytują cały ruch sieciowy i nakładają na niego reguły dostarczone przez nas w konfiguracji. Niektóre z możliwości, jakie daje nam Istio z wykorzystaniem Envoya:

• Szczegółowa kontrola ruchu sieciowego za pomocą zasad routingu dla HTTP, gRCP, WebSocket oraz pakietów TCP.
• Odporność na problemy w funkcjonowaniu sieci, takie jak retry, failovers i circut breakery.
• Zabezpieczenie sieci za pomocą polityk bezpieczeństwa oraz limitowanie obciążenia kontrolowane konfiguracyjnie.

Control plane (Istiod) to zestaw komponentów, które dynamicznie zarządzają działaniem naszego Service Mesh. Poszczególne komponenty są odpowiedzialne za:

• Service discovery i load balancing (Istio utrzymuje tzw. service registry, dzięki któremu proxy Envoya mogą kierować ruchem i rozkładać obciążenie sieciowe na wiele instancji serwisów).
• Konfigurację routingu z poziomu plików konfiguracyjnych, które są tłumaczone i następnie propagowane do niskopoziomowego API Envoya.
• Obsługę bezpieczeństwa komunikacji wewnątrz klastra za pomocą mTSL oraz zarządzanie certyfikatami dla tejże komunikacji.

Co dostajemy prosto z pudełka

Instalację Istio możemy rozpocząć od wykorzystania jednego z przygotowanych profili konfiguracji, a następnie wprowadzać dodatkowe zmiany adekwatnie do naszych potrzeb.

Na początek najlepiej jest skorzystać z profilu domyślnego, który poza bazową konfiguracją control plane i proxy dostarcza dodatkowo komponent istio-ingressgateway. Pozwala nam on na monitorowanie i kontrolę ruchu sieciowego wchodzącego do wewnątrz klastra Kubernetesa.

W bazowej instalacji, bez jakichkolwiek dodatkowych zmian, otrzymujemy w pakiecie możliwości monitorowania ruchu w klastrze, automatycznie zbierane są również metryki (takie jak liczba oraz czas zapytań i odpowiedzi). Jednocześnie możemy też śledzić każde zapytanie skierowane do klastra, jak również wykrywać problemy w komunikacji, takie jak wąskie gardła lub zwiększenie błędnych odpowiedzi z jednego z mikroserwisów.

Dodatkowo cały ruch sieciowy wewnątrz klastra jest automatycznie szyfrowany z użyciem mechanizmu mTLS, czyli wzajemnego uwierzytelniania mikroserwisów za pomocą certyfikatów X.509, których zarządzaniem również zajmuje się Istio.

Jak widać, sporo zyskujemy już przez samo użycie Istio, bez jakichkolwiek dodatkowych konfiguracji z naszej strony. Jednak przy niewielkim wysiłku wykorzystanie Istio otwiera przed nami bardzo dużo dodatkowych możliwości. Poniżej opiszę jedną z nich.

Przykład użycia Istio – zarządzanie ruchem sieciowym

Załóżmy, że pracujemy nad aplikacją złożoną z kilku aplikacji, której architekturę przedstawiono na poniższym schemacie.

W szczególności zwróćmy uwagę, że zainstalowano trzy wersje serwisu ‘review’, chociaż na ten moment wydaje się, że ruch sieciowy trafia tylko do wersji v1.

Konfiguracja Istio potwierdza, że tylko wersja v1 może przyjmować zapytania z serwisu productpage. Załóżmy dodatkowo, że nieużywany na ten moment moduł ratings służy do  nowej funkcjonalności, dostępnej dopiero od v2 usługi reviews. Jeśli w ten sytuacji chcielibyśmy skierować część zapytań (w naszej konfiguracji 10%) do nowej wersji usługi (tzw. canary deployment), możemy to zrobić za pomocą niewielkiej modyfikacji istniejącej konfiguracji.

Efekt takiej zmiany na ruch sieciowy w naszej aplikacji wygląda następująco:

Jak widać, około 10% ruchu do serwisu reviews trafia teraz do wersji v2, która prawidłowo komunikuje się z serwisem ratings. Kolejnymi krokami mogłyby być monitorowanie nowych usług i stopniowe manipulowanie wagami aż do ostatecznego całkowitego przejścia na nową wersję funkcjonalności.

Zwróćmy jednak uwagę, że ruch sieciowy w poprzednim przykładzie był kierowany do konkretnych wersji serwisu reviews losowo, tym samym nie mamy kontroli nad tym, pod jakim warunkiem lub dla jakiego użytkownika nowa funkcjonalność będzie dostępna.

W kolejnym przykładzie chcemy udostępnić dla użytkowników aplikacji możliwość wzięcia udziału w testowaniu nowej funkcjonalności. Wiąże się to z kierowaniem wybranej części ruchu sieciowego do nowej usługi na podstawie atrybutu zapytań HTTP. W realizacji tego zadania pomoże nam dodawanie niestandardowego headera do wszystkich zapytań (np. x-beta) i kierowanie ruchem na jego podstawie.

Taka prosta zmiana w naszej początkowej konfiguracji pozwala na zrealizowanie opisanego wymagania.

Alternatywnym podejściem do powyższej sytuacji, zmniejszającym ryzyko nieprawidłowego działania nowej funkcjonalności, jest wykorzystanie mechanizmu traffic mirroring. W tej konfiguracji decydujemy się kierować cały ruch sieciowy do stabilnej wersji v1, jednocześnie wysyłając kopię całego ruchu do wersji v2, która w tym momencie jest niedostępna dla użytkowników, ale możliwa jest analiza i testowanie niesprawdzonej wersji w środowisku produkcyjnym.

Poniższa konfiguracja umożliwia opisany wyżej traffic mirroring:

W tej konfiguracji 100% ruchu jest skierowane do wersji v1, jednocześnie 100% ruchu jest też kierowane do v2, z tym że użytkownik otrzyma odpowiedź zawsze ze stabilnej wersji serwisu. Możemy oczywiście kontrolować ilość ruchu odbijanego w stronę v2 za pomocą parametru konfiguracji mirrorPercentage.

Podsumowanie

Istio to bardzo rozbudowane narzędzie, a opisane przykłady to tylko niewielka część jego dużo większych możliwości. I chociaż próg wejścia nie jest najmniejszy, to zdecydowanie jest warto ze względu na korzyści. Zdecydowanym ułatwieniem jest możliwość rozpoczęcia od domyślnej konfiguracji, która wymaga niewielu zmian w istniejącej aplikacji. Mam nadzieję, że ten artykuł zachęci was do wypróbowania Istio w waszych projektach.

Przeczytaj także: Mikroserwisy – nowa jakość w międzynarodowych projektach IT