Łukasz Kałużny: Cześć, słuchajcie Patoarchitektów. Prowadzą Łukasz Kałużny…

Szymon Warda: I Szymon Warda. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io/19. To o czym dziś Łukaszu? Dzisiaj znowu o API Gateway. Szczególnie o wzorcu API Agregation i paru innych rzeczach z tym związanych. Tak patrząc anegdotycznie wyszło nam kilkanaście stron notatek w trakcie przygotowywania linków i innych rzeczy. No i wyszło na to, że mieliśmy kupę w niektórych miejscach być może niepotrzebnych dyskusji akademickich, purystów i idealistów, ale świat nie idzie tą drogą zdecydowanie.

Szymon Warda: Tak. I jak się niektórzy pytają, ile czasu idzie przygotowanie jednego odcinka, to ten chyba przebił rekordy i było z 8?

Łukasz Kałużny: 8 godzin rozmów.

Szymon Warda: Tak na 20 minut odcinka. Zobaczymy.

Łukasz Kałużny: Zobaczymy co będzie. Dobra, to co czytałeś ostatnio?

Szymon Warda: Ja tym razem odstępstwo od InfoQ, czyli mianowicie przez święta udało mi się coś większego, czyli mianowicie uporządkowanie wiedzy w kontekście Kubernetesa i Kubernetes in Action Manninga. Bardzo dobra książka, mimo że Kubernetesa znałem i to bardziej było w kontekście uporządkujmy sobie, zobaczmy gdzie co brakuje. To po pierwsze, nie nudziłem się, a po drugie, fajnie przeprowadzona narracja, ładne powiązania, nie jest taka wyrywkowa. Naprawdę byłem pod wrażeniem jak dobrze się przez to przechodzi.

Łukasz Kałużny: I to jest ciekawe, bo można w sumie w dowolnym momencie otworzyć po spisie treści i wejść do danego tematu problemu.

Szymon Warda: Tak, ale Ty masz, nawet czytając ją po kolei, też się ją dobrze czyta w ogóle. Więc naprawdę jakby ktoś polecał książki, książki do Kubernetesa, szczerze mogę polecić. Super jest.

Łukasz Kałużny: Ja jako drugą zawsze polecam, bo ta czasami głęboko wchodzi. Na pierwszy rzut lepszy jest “Kubernetes: Up and Running”. W szczególności, że chyba nadal jest za darmo druga edycja. Microsoft daje w zamian za dane osobowe.

Szymon Warda: A faktycznie było tak.

Łukasz Kałużny: Tak i tam ona jest chudsza, więc można ją szybciej przeczytać, a potem zagłębić się w In Action w szczegółach.

Szymon Warda: Możliwe. Właśnie wejście w szczegóły mi pasowało, bo już znałem te pojęcia, więc to było takie ok. Na każdej stronie był jakiś smaczek, coś tam się dało znaleźć, więc było niezłe. A co u Ciebie?

Łukasz Kałużny: Wiesz co, mamy nową dekadę, więc trafił mi się wpis podsumowujący technologię w poprzedniej dekadzie i jak to wygląda. Więc było dużo różnych zagadnień poruszonych co się pojawi, co się pojawiało, na rzecz czego i dlaczego.

Szymon Warda: Czytałem, faktycznie fajne. To, co mnie ucieszyło tam i mam nadzieję będzie się kontynuowało, to są właśnie streamy i cały ruch w związku z observability. Bo zaczęło się, ale mam wrażenie, że ten ruch się jeszcze nie rozkręcił i to jest takie, nawet patrząc po specyfikacji, która jest otwarta i co się dzieje w tym obszarze, to to dopiero początek.

Łukasz Kałużny: Tak, patrząc się, że to jest moja… Dekadami to będzie moja druga zakończona dekada w IT, bo…

Szymon Warda: Zakończy się dopiero jak wejdziemy w rok kolejny, dekada.

Łukasz Kałużny: Tak, dekada.

Szymon Warda: Tak.

Łukasz Kałużny: Od zera czy… Dobra, nie będę wchodził teraz się z tobą kłócił. Ale to co się pojawiło, to jeszcze inną rzeczą to, że Continuous Integration teraz jest normą.

Szymon Warda: Tak.

Łukasz Kałużny: Powinno być normą, może inaczej, powinno być normą. I druga rzecz, trochę powiązana, że API is the king, zaczęło się takie, jak to zostało w tym określone Appification of Things.

Szymon Warda: Tak, ja się zgodzę i fajną miał uwagę Mark Rendle i pamiętam z prezentacji, w ogóle polecam prezentację. Tam: my ten year plan as a developer. I on mówił, że całe właśnie AI-e, Alexy i tak dalej, one ruszyły bardzo mocno cały ruch appification, bo nagle mamy inne API, nagle już nie jest to web. Jeszcze tylko aplikacje mobilne i tak dalej. Ale faktycznie, zgodzę się, jak najbardziej. Dobrze.

Łukasz Kałużny: To zaczynamy.

Szymon Warda: Tak, będziemy mówili o API Gateway. I to ważne, ta różnica, o API Gateway, nie o API proxy. Czyli będziemy mówili o funkcjonalnościach, wzorcach, jak zaznaczyłeś, API agregation. Które też często nazywane bywa jako API composition.

Łukasz Kałużny: Jak mówimy w ogóle o API Gateway. To nasuwa się jedno słowo - pierdolnik. W założeniu, w teorii API Gateway powinien być, albo jest, anty corruption layer, utrzymuje wersjonowanie, czy buduje ten cały pierdolnik, którym jest tłumaczenie protokołów, jeżeli je chcemy czy inne funkcjonalności translacji tego wszystkiego.

Szymon Warda: Tak i ten pierdolnik tam pewnie będzie. Z tą różnicą, że często to, że mamy właśnie ten pierdolnik wynika z tego, że nie myślimy jak podzielić. Bo właśnie API Gateway staję się takim workiem na wszystko, a ten worek można ładnie podzielić horyzontalnie. I w tym momencie jeżeli wprowadzimy wzorzec, który jest trochę promowany, wydaje mi się, że jest trochę za mało promowany, czyli mianowicie BFF, czyli Backend For Frontend, który bardzo ładnie, wertykalnie właśnie dzieli API Gateway.

Łukasz Kałużny: Dobra, to wprowadziłeś nowe pojęcie, to powiedz w dwóch zdaniach czym jest Backend for Frontend.

Szymon Warda: Upraszczając, stworzenie osobnego, dedykowanego endpointu API per typ konsumenta. Przykład, Ci konsumenci mogą korzystać z tych samych danych, ale mieć inne API. Przykład jaki jest? To jest na przykład strona webowa i aplikacja mobilna. Niby pokazują to samą listę produktów, ale mogą wymagać innych pól. I to właśnie daje możliwość obcięcia i tak dalej. Bardzo duża elastyczność i samo wprowadzenie tego użycia dużo ułatwia.

Łukasz Kałużny: Dobra i po co robimy BFF-a?

Szymon Warda: Elastyczność dostosowania. To wynika z tego, że załóżmy co z tego, że na start mamy, bo wyglądają tak samo te API, mogą różnie się zachowywać wraz z upływem czasu. Ograniczenie ryzyka zmiany. Jak wprowadzamy zmiany w wyświetlaniu produktów, to wiemy, że w tym obszarze wybuchnie nam tylko aplikacja mobilna, nie martwimy się innymi rzeczami. Zawężenie zakresu wersjonowania. To jest też bardzo, bardzo fajne. Nagle będziemy mieli 20 numerków, tylko na jednym, będziemy mieli 2 numerki, na kolejną, na przykład na aplikacji mobilnej będziemy mieli dużo więcej numerków, bo nie zmusimy niektórych ludzi do migracji wersji. I to jest bardzo fajne.

Łukasz Kałużny: Ja tutaj dorzucę od siebie też łatwiejsze security, przygotowywanie go, bo mamy dużo funkcjonalności w API Gateway’ach, które potem możemy bardzo łatwo rozbić w takie konteksty i dostosować się bez kombinowania i rozdzielić to od siebie w zależności od tego co mamy. Czyli inne wzorce, inne zachowanie przy mobilce, inne zachowanie przy webie przykładowo czy przy innym jakimś wbudowanym kliencie. Kolejną rzeczą, którą mówimy często o szybkości, to łatwiejsze mockowanie. Bo może się okazać, że w jakimś przypadku chcemy dorzucić coś do API, jakieś nowe pola i inne rzeczy, nie są jeszcze zaimplementowane, więc w trakcie developmentu możemy sobie te requesty na przykład porozszerzać tam, gdzie tego potrzebujemy.

Szymon Warda: Tak, i w tym momencie tym mockowaniem zajmuje się tylko zespół frontendowy, bo oni się tym zajmują i wiadomo, nie muszą wysyłać ticketów do backendu i tak dalej, sami to robią. A często API Gateway takie opcje mockowania udostępniają bardzo prosto. To co dla mnie jest też bardzo ważne, jak jeszcze mówimy właśnie o BFF-ach, to jest jak projektujemy API HTTP, to to jest takie bilansowanie między zwracaniem zbyt dużej ilości danych w request’cie, a posiadaniem zbyt dużej ilości requestów. To jest granulacja. Albo będziemy mieli wyszczegółowione, albo takie wielkie. BFF nadaje to właśnie grupowanie jak powinny wyglądać i to jest bardzo, bardzo fajne.

Łukasz Kałużny: Tak naprawdę jedną z podstawowych funkcji, która dzieje się w ramach BFF-a, to będzie API Agregation, o którym wspomnieliśmy w temacie odcinka.

Szymon Warda: No to teraz Ty. W dwóch zdaniach, czym jest API Agregation?

Łukasz Kałużny: Wiesz co, to jest głównie łączenie wielu requestów po stronie Application Gateway’a i często zdarzająca się gdzieś manipulacja tymi requestami, żeby je połączyć.

Szymon Warda: Okej. W takim razie czemu robić API Agreagation? Bo to jest taki śliski obszar, że wchodzimy w rozumienie requestów, co może być antypatternem? Takie bilansowanie. Gdzie pozwolić sobie na odrobinę antypatternu, żeby mieć wartość, a gdzie to nie ma sensu. Więc czemu robić API Agregation?

Łukasz Kałużny: Wiesz co, jeżeli tam patrzymy na to, czemu? Tak jak powiedziałem, to agreguje nam requesty z wielu serwisów, więc będzie wtedy to jedno takie miejsce. Przy tym co powiedziałeś, przy BFF-ie na przykład będziemy mieli taką ładną, wyspecyfikowaną metodę, na przykład produkty, która nam zbierze wszystkie rzeczy poboczne, a nie będziemy musieli walnąć, żeby wyświetlić coś na stronie czy w mobilce, będziemy musieli walnąć 5, 10, 15 requestów gdzieś po kolei. Więc pozwala nam to w elastyczny sposób zebrać do kupy i przekazać i często na podstawie requestów.

Szymon Warda: To teraz co się jeszcze dzieje? Bo jak mówimy, że zbieramy requesty, to wchodzi nam cały problem generalnie, jak tylko zbieramy? Czy zbieramy je równolegle? To jest taka fajna, fajna opcja, to działa. Ale nagle jest taka śliska granica, że wyjdziemy na zbieranie sekwencyjne. I tu wchodzimy w rozumienie. I w tym momencie nasz API Gateway nie staje się generalnie taką prostym przelotką, tylko staje się czymś co orkiestruje, staje się ESB.

Łukasz Kałużny: Tak i tutaj trzeba purystycznie mówiąc, to będzie orkiestracja API. No i z założenia, jak popatrzymy, to ja będę preferował to, żeby na przykład z URL-a czy z requestów wziąć na przykład ID czegoś i zebrać o tym informacje z wielu równoległe, niż wprowadzać właśnie taką state fullową workflow egzekucję tego.

Szymon Warda: Tak, dokładnie, to co zacząłeś, wprowadzeniem workflow do API Gateway’a, bardzo śliskie i w ogóle stanu też naprawdę przed tym przydałoby się bronić. Jak do końca? To będzie podsumowanie na końcu odcinka jak to wygląda.

Łukasz Kałużny: Tak, ale to co powiedziałeś właśnie, jak mamy to, to zebranie sekwencyjne jest jakimś stanem tymczasowym.

Szymon Warda: Tak. Co jest jeszcze ważne? Całe czasy, latencje i nasze iterowanie, jak mówimy o wielu serwisach, iterowanie po stronie naszego API Gateway. Między naszymi serwisami wewnętrznymi ma dużo mniejszą latencję i jest łatwiejsze niż robienie tego przez klienta. Bo skoro on ich potrzebuje, to pytanie kto tą iterację zrobi? Łatwiej jest tą iterację zrobić właśnie w Gateway’u.

Łukasz Kałużny: Tak. Czyli to co powiedziałeś, jeżeli klient ma, przykładowo komórka będzie miała słabe łącze, czy ktoś łączy się przez internet do naszej usługi, nie wiemy jakie jest stabilne, to minimalizujemy ilością requestów, czyli odpadnie nam całe nawiązywanie SSL-a, opóźnienia, zabawy z DNS’em i innymi rzeczami. Czyli to sumując co jest na każdy request nam potrzebne. No i po stronie systemu też zmniejszamy ilości przeskoków pomiędzy mikroserwisami jak mamy robione różne requesty, bo czasem można zobaczyć jak request dla frontendu potrafi zrobić hopa przez 5, 6 usług, co nie powinno mieć miejsca zazwyczaj.

Szymon Warda: Dokładnie, ale jeżeli mówimy o API Agregation tak naprawdę…

Łukasz Kałużny: Wiesz co, ja jeszcze bym jedną uwagę dodał, taką bardzo istotną, że trzeba się tutaj uważać i namęczyć, żeby przypadkiem te API Agregation nie dawało nam zbyt wielkich zbiorów, żebyśmy się wydajnościowo nie zabili na takim API Agregation na Gateway’u. Oraz trzeba uważać na stronicowanie, bo też potrafi być problematyczne przy takim podejściu.

Szymon Warda: Tak, tylko jak mówimy o podejściach, to jest też inne podejście niż względem API Agregation. Jest cały GraphQL, który nam zmienia podejście z tym, jak podchodzimy do stronicowania i jak podchodzimy w ogóle do wyboru danych, które potrzebuje klient. I to jest takie ciekawe podejście, bo jest niemalże dokładnie odwrotne względem całego API Agregation.

Łukasz Kałużny: Tak, ale jest zgodne z BFF-em.

Szymon Warda: Jak najbardziej tak. Dobrze, no to przejdźmy sobie przez różnice. Dla mnie taką jedną z najbardziej oczywistych to jest złożoność projektowania. W API Agregation mamy dwie opcje tak naprawdę, jeżeli ruszamy z jakimś BFF-em.

Łukasz Kałużny: API Agregation i API Gateway’em, bo to trzeba troszeczkę powiedzieć, to uwspólnić przy porównaniu z GraphQL-em.

Szymon Warda: No to mamy dwie opcje. Albo bierzemy jakieś istniejące API dla konkretnego, dla innego, jakiegoś frontendu, kopiujemy i ten zespół ma wyciąć to, czego nie potrzebuje. Jak doskonale wiemy, ludzie nie usuwają, nie wycinają rzeczy i mają albo zbyt duży requesty, albo mają zbyt dużo widocznych metod. Niefajnie. Druga opcja to jest to, że zaczynają z pustego zestawu i dodają sobie to, co potrzebują. To znowu wymaga więcej czasu, a można by to zrobić inaczej.

Łukasz Kałużny: Tak. No i przy GraphQL-u jest to o tyle ciekawe, bo to z założenia GraphQL jest specyfikacją query’owania, zapytywania restowych API. Więc możemy tak naprawdę wszystkie mikroserwisy zebrać w takim serwerze GraphQL-owym do kupy i wystawić swój cały schemat wszystkiego co mamy. Są nawet narzędzia do konwertowania Open API Swagerów właśnie do schematów GraphQL-owych, więc naprawdę można szybko zacząć. I tutaj jest o tyle ciekawe, że przy tym, na tym, zamiast na API Gateway’u, nie martwimy się o to kto co będzie pobierał, ponieważ nasz klient końcowy bierze to co chce.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Sam o to pyta. I teraz przejdźmy sobie do problemu, który jest w GraphQL-u, a w API Gateway’u można nim dobrze zarządzić. Jest to wersjonowanie. I tutaj jeżeli sobie szczerze na to popatrzymy, to sam GraphQL do wersjonowania nic nie ma w swojej specyfikacji.

Szymon Warda: Coś tam ma, ale niewiele.

Łukasz Kałużny: Coś ma. I te coś ma tak naprawdę znajdziemy to dopiero w dobrych praktykach i między zdaniami można wyczytać, że jakie wersjonowanie, GraphQL powinien iść razem z całym developmentem i klientem, wszystko powinno iść do przodu. Więc można powiedzieć, że wersjonowania nie ma.

Szymon Warda: Nie ma. Natomiast znowu w API Agregation, ponieważ to bazuje na http zwykłym, na czasownikach i tak dalej…

Łukasz Kałużny: Raczej na całym Gateway’u, implementacji całego Gateway’a.

Szymon Warda: To jest to znowu bardzo proste. Dajemy to znane V1, V2. Dobrą praktyką, którą stosuje Microsoft, jest wersjonowanie nie V-kami, tylko datami, datami API. To jest dość czytelne. I mamy kilka opcji do wyboru tak naprawdę. Mamy to, że możemy albo wersjonować całe API albo wersjonować API poszczególnego serwisu. Czyli przykład, jak mamy example.com/API/v1 czy example.com/API/user, czyli konkretny serwis /v1. I jeżeli nie mamy BFF-ów, to nagle to jest taka ciężka decyzja właśnie co, jak, gdzie wersjonujemy. Czy z całego naszego API, tych wersji za chwilę będziemy mieli bardzo dużo poszczególnego serwisu, mamy leaky abstraction. A jak mamy BFF-a to wersjonujemy całego BFF-a i to ma sens, bo mamy kontekst użycia i to jest super. Więc do tego się sprowadza.

Łukasz Kałużny: Raczej patrząc jeszcze tam w środku, jak sobie popatrzymy, tych schematów wersjonowania jest teraz masa. Ja też się spotkałem w niektórych przypadkach, że wersjonujemy w ogóle całym hostem, czyli że mamy APIv3.coś_tam, widziałem w paru miejscach. Zupełnie łatwo przepinamy się zupełnie na nowy endpoint i dziękujemy. Więc jest to też znowu rozważanie. Chyba te leaky abstraction jest najważniejsze, żeby nie schodzić w niektórych miejscach za nisko z wersjonowaniem poszczególnych komponentów, tylko bardziej opisywać całość.

Szymon Warda: Tak, dokładnie. Idąc dalej, jeżeli mówimy o wersjonowaniu, to od razu powinniśmy powiedzieć o kontraktach. I ponownie, przy API Agregation, API Gateway’u mamy open API. Jak ktoś preferuje taką prehistorię, mamy WSDL-a, możemy mieć różne kontrakty. Jeżeli mamy kontrakty, wiemy dokładnie co serwis zwraca, możemy mieć takie protokoły komunikacji, jak proto buffy, GRPC, gdzie znamy kontrakt i go potrzebujemy, bo inaczej tej wiadomości nie rozszyfrujemy.

Łukasz Kałużny: W wielu wypadkach jeszcze przy API Gateway-ach, ta translacja jest dość fajna, bo możesz powiedzieć, najczęściej jest to WSDL, tu Rest i na odwrót, ale pewnie dla GRPC i zaraz innych też się znajdą.

Szymon Warda: Za chwilę się też pojawiają teraz tak naprawdę jeszcze całe windowsowe komunikacje, które teraz są tłumaczone na GRPC na przykład.

Łukasz Kałużny: Tak, bo WCF-y, są teraz te automaty do tłumaczenia WCF-ów na GRPC się pojawiły.

Szymon Warda: Dokładnie.

Łukasz Kałużny: Inną rzeczą będzie przy GraphQL-u. I tutaj czy kontrakt jest definiowany przez zapytanie? Bo tak naprawdę w GraphQL-u mamy schemat, w jaki sposób możemy się o co i jak się odpytać. A jeżeli popatrzymy się, czym jest kontrakt, to tak naprawdę przy możliwości zapisów to będzie kontrakt. Więc tutaj jest to troszeczkę rozróżnianie akademickie, ale ono będzie ważne, czym jest schema a czym kontrakt. Więc przy zapisach możemy powiedzieć o kontraktach w GraphQL-u, a przy reszcie możemy powiedzieć o schemacie.

Szymon Warda: Mówiąc prosto, mając schemat nie zrobimy z tego GRPC. Mając kontrakt zrobimy z tego na przykład GRPC albo proto buffy.

Łukasz Kałużny: Tak, to jest…

Szymon Warda: Ta różnica.

Łukasz Kałużny: Jest to dobre porównanie.

Szymon Warda: Schemat nam gwarantuje co możemy zrobić, ale nie daje gwarancji jak to zwrócimy.

Łukasz Kałużny: Dobra i teraz będzie o testowalności, bo jest to dość ciekawe z tego punktu widzenia. I w przypadku API Gateway’ów Agregation te testowanie jest proste, bo korzystamy ze stosu narzędziowego, który znamy i znamy te wszystkie gałęzie zapytań, wszystkie IF-y i to, czego oczekujemy w zwrocie i mamy skończoną ilość opcji.

Szymon Warda: Tak, jak coś agregujemy, to dokładnie wiemy co agregujemy, jak agregujemy, na jakim warunku agregujemy. A jak spojrzymy na GraphQL, to klient definiuje jak nasze dane połączy, jak je zwróci i ten zbiór kombinacji jest dużo, dużo większy. W ogóle takie wrażenie, jakie odnosimy przeglądając właśnie cały ekosystem GraphQL, to jest, że on już jest trochę na rynku. To już tak jak patrząc na rzeczy, które wyłoniły się z Node’a, to już powinny być dojrzałe, a tam dalej są takie dyskusje o dość bazowych rzeczach, więc ten tooling wokół jest trochę już mniej dojrzały. Zdecydowanie.

Łukasz Kałużny: Tak, jest tego mnogo. Klientów, serwerów jest mnogo. To jest ciekawe, ale jeszcze nie ma takiego stopnia dojrzałości.

Szymon Warda: Tak. I teraz wchodzimy w to znowu, gdzie GraphQL trochę błyszczy, większość ludzi interpretuje, że błyszczy. Tak powiem, że nie zawsze. Języki zapytań, GraphQL jest stworzony do bycia językiem zapytań, więc zapytania proste wyglądają fenomenalnie. Łatwo możemy filtrować, zawężać robiąc selecty to jest super. No ale Ty pewnie za chwilę powiesz, że w API Agregation jest jak?

Łukasz Kałużny: No właśnie jest z założenia API Gateway, w teorii query’owanie powinno być trudne. To jest taka teoria. Jak sobie pójdziemy, zobaczymy Elasticsearcha, być może to co kiedyś Microsoft wymyślił z ODatą, to naprawdę można byłoby tam włożyć bardzo skomplikowane rzeczy poprzez takie restowe API, udostępnić.

Szymon Warda: Tak, Rest jest elastyczny mimo wszystko, to ok, to wszystko się dzieje w poście albo w czasowniku search, różnie z tym bywa. Ale to dalej, to nie jest znowu takie czarno-białe porównanie generalnie, że jeden jest dużo lepszy od drugiego akurat w tym obszarze.

Łukasz Kałużny: GraphQL projektowo będzie prostszy do zapytań i do użycia. Na przykład jeżeli powiemy, że wystawiamy GraphQL-a, rzucimy to developerom, na pewno prościej będzie to zaimplementować po stronie na przykład web aplikacji.

Szymon Warda: Tak. A propos teraz prostoty, to Ty masz teraz w kontekście…

Łukasz Kałużny: W kontekście odczytów i zapisów. Jeżeli sobie popatrzymy, no to API Gateway, mamy kontrakty i dziękujemy tak naprawdę za użycie i tyle. Używamy.

Szymon Warda: Tak i mamy czasowniki, doskonale wiemy, jak to zrobić. W GraphQL-u to ok, można, jest, sprawia wrażenie takiego lekko trochę kulawego. Rzecz, która została dodana do GraphQL-a, można, ale ewidentnie to jest coś, co się dużo lepiej spisuje na odczycie.

Łukasz Kałużny: Bo GraphQL ma swoje inputy, mutację. Ja tak, jak tak patrzę, nie czuję jak to ugryźć. Jak się pierwszy raz na to patrzy, to nie ma poczucia jak to ugryźć w przeciwieństwie do API Gateway’ów, jak się z tym, jak sobie z tym poradzić, jest jasne. Tutaj najczęściej API proxy przy zapisie. Dziękujemy.

Szymon Warda: Dokładnie i mamy jasny kontrakt co możemy jak zapisywać, bo mamy kontrakt tego naszego posta czy puta. I wchodzimy dalej w takim razie w obszar, który też w GraphQL kuleje - cache’owanie. Czemu? Ponieważ przy API Agregation doskonale wiemy, to są zwykłe czasowniki http. Wiemy, że gety możemy cashe’ować, mamy nagłówki jak długo i tak dalej, i tak dalej. Korzystamy z znajomości http, infrastruktury http z ostatnich kilkudziesięciu lat.

Łukasz Kałużny: Tak i masz całą rozproszoną infrę pod tym pod spodem, rozproszone cache. Możesz sam zdecydować przy politykach takiego requesta, jak to ma być zacache’owane, albo kiedy, co i jak. A w GraphQL-u znowu jest takie bardzo śmiesznie skomentowane, niby jest http. Więc tutaj trzeba się, jasno jest powiedziane, że musimy się namęczyć. To tak w dobrych praktykach.

Szymon Warda: To jest post http.

Łukasz Kałużny: Tak, post http. To jest też właśnie istotne, że te zapytania to są posty http. I tutaj taki jasny przekaz, że będziesz musiał się przy tym cache’owaniu namęczyć, czy to client side czy to server side.

Szymon Warda: Tak.

Łukasz Kałużny: I ostatni, rate limiting, takich naszych różnic. Więc jak wygląda w API Gateway’u ten rate limiting?

Szymon Warda: Jest trywialnie prosty, bo to jest doszczegółowienie rate limiting. Takie proste ile requestów jest trywialne w jednym i w drugim. Ale bardzo często, na przykład w Azure jest tak, że różne requesty mają różne limity.

Łukasz Kałużny: Różne API, różne serwisy, które chcielibyśmy podłączyć bezpośrednio.

Szymon Warda: Dokładnie, załóżmy prosty myk, query’owanie ma z reguły dużo wyższe limity. A na przykład operacje delete’a, puta, update’a, takie operacje zmieniające cokolwiek, mają w tym momencie już niższe limity albo więcej za nie płacimy. Co więcej, też ma odpytywanie o dane bardziej złożone, też więcej za nie płacimy. I to jest trywialne w API Gateway Agregation. A w GraphQL-u?

Łukasz Kałużny: W GraphQL-u jak się popatrzy to jest rzeźbienie, jak się na tą chwilę popatrzy, żeby zrobić coś inteligentniejszego w tym miejscu.

Szymon Warda: Wchodzimy do tego, że musimy rozumieć request. Praktycznie musimy sparsować ten request GraphQL-owy, żeby zrozumieć co on robi, o co się pyta. I pytanie, jak bardzo zahacza o te serwisy, które są droższe i powinny mieć inny limiting.

Łukasz Kałużny: Wejdź sobie tam w bebechy i niestety się z tym namęczyć. Jak sobie popatrzymy to implementacje rzeczy na API Gateway infrastrukturalnie, technicznie są o wiele bardziej dojrzałe w środku.

Szymon Warda: Tak.

Łukasz Kałużny: Czyli to, co też mówiliśmy w poprzednim odcinku porównując Enterprise API Gateway z API Gateway, że bardzo często za zwykłego API Gateway’a służą te rozwiązania Enterprise’owe, które funkcjonalnościami są przeładowane tak naprawdę i tym, co nam mogą zaoferować.

Szymon Warda: Dokładnie. Skoro mówiłeś o przeglądaniu implementacji, no to warto w tym momencie byłoby rzucić okiem na linki, które nam się napatoczyły w kontekście przeglądania materiału do tego odcinka.

Łukasz Kałużny: Jest ich trochę. Dwa chyba na start, które warto od Thoughtworksa polecić.

Szymon Warda: Tak, zdecydowanie. Jeden jest o Overambitious API Gateways, czyli właśnie ten problem, żeby gateway’e nie miały zbyt dużo. I naprawdę ciekawy wpis, zdecydowanie. I drugi?

Łukasz Kałużny: Drugi to jest Thoughtworks pomagał dla SoundCloud przy rozbijaniu, robieniu porządków z ich monolitami, mikroserwisami i tam również do kontekstu wprowadzili BFF-y, wprowadzili backendy dla frontendów dedykowane. I jak sobie popatrzymy na schemat, no to sprowadzili tego dość sporo…

Szymon Warda: Bo też sporo tego powinno być.

Łukasz Kałużny: Tak, sporo tego powinno być. Jeżeli sobie rzucę okiem, no to mamy mobile BFF-y, webowe, dla urządzeń jakichś wbudowanych, kawałek tego webba. Dla konfiguracji urządzeń wbudowanych, czyli jeżeli mamy jakiś głośnik Sonosa czy czegokolwiek, to dopięcie się do niego. A z drugiej strony jeszcze BFF for Partners, który wystawili tą część webową. Więc tutaj tych BFF-ów było sporo zbudowanych.

Szymon Warda: Dobra, wrapujemy ten odcinek. Wnioski jakie mamy?

Łukasz Kałużny: No to wiesz co Szymonie, bo trochę nie odpowiedzieliśmy w trakcie i to jest rzecz. Co z logiką biznesową w API Gateway’u?

Szymon Warda: Możemy się akademicko naginać, żeby jej nie robić i tak dalej, bo nie powinniśmy, ale tak naprawdę ona tam będzie. Od tego nie uciekniemy. Trzeba się z tym pogodzić. Trzeba ograniczać jej ilość, ale ona tam będzie, bo API Gateway trochę od tego jest tak naprawdę, żeby takie rzeczy mieć. To jest taka warstwa, co powiedzieliśmy, to jest taki ładny anti-corruption layer, w którym pierdolnik będzie. Ten pierdolnik jest tym długiem technologicznym, który powinniśmy spłacić. Pytanie, czy chcemy i pytanie, kiedy go chcemy spłacić?

Łukasz Kałużny: Dlatego ja bym dorzucił właśnie do Twojego, że warto ten temat przeambicjonowanych API Gatewayów zrobić sobie na ten temat, przeszukać, poczytać, zobaczyć co inni, bo wniosków jest dużo różnych. I właśnie gdzie znaleźć ten balans? I to trzeba samodzielnie dokonać tej decyzji. Dobrze, żeby ktoś od integracji aplikacji tego nie robił, bo zbuduje drugie ESB.

Szymon Warda: Bardzo ryzykowne. Dokładnie.

Łukasz Kałużny: Tak. Ja dorzucę od siebie ogólnie, że GraphQL, jak sobie popatrzymy, jako BFF dla frontendów jest genialny.

Szymon Warda: Tak.

Łukasz Kałużny: Przez to, że brak wersjonowania innych rzeczy, to nam nie przeszkodzi, bo zwykle walniemy przy release’ie nowej wersji strony, deploy’ujemy nową wersję schematu, Ctrl+F5 i nasza przeglądarka z naszą aplikacją już działa. W kontekście innych rzeczy, czy zewnętrznych, ten Rest jest o wiele w ogóle… Może Rest, http API jest o wiele wygodniejsze.

Szymon Warda: Możemy wersjonować i jest czytelniejszy. To nawet jak rozmawialiśmy czasami w umowach z partnerami zawieramy kontrakty i schematy, w umowach samych. I w tym momencie lepiej, żeby ta umowa nie była GraphQL-em, ten schemat, tylko niech to będzie po prostu zwykłe http. Łatwiej po prostu jest.

Łukasz Kałużny: Tak, mamy nad tym kontrolę.

Szymon Warda: Tak, jeszcze dorzucę taki dość ważny wniosek, który właśnie mi się napatoczył. To jest to, że BFF-y dają do API Gateway’a to, co brakowało bardzo dużo. To jest wprowadzanie kontekstu użycia tych metod. Bez BFF-ów to mamy metody i nikt nie wie po co one są, kto z nich korzysta i czego potrzebuje. Jak wprowadzamy BFF-y, to dzielimy to w ten sposób i wiemy kto czego potrzebuje i możemy to nawet wygaszać, jeżeli nagle ten frontend już nie istnieje albo nie jest potrzebny.

Łukasz Kałużny: I teraz co ważne przy takich API Gateway’ach? Ten backend for frontend nie musi leżeć na oddzielnym API Gateway implementacyjnie, bo to jest logiczny podział, a nie fizyczna implementacja. To też przydaje się to zrozumieć, bo często te instancje potrafią być bardzo drogie. Jak wezmę Azure’owe API Management za wersję premium, którą można wpiąć do VNetu i posiada te wszystkie funkcjonalności co trzeba, no to instalacja kosztuje chyba 2300 euro za miesiąc czy coś takiego. I ludziom się wydają to horrendalne pieniądze. Ale są tam produkty, które każdy taki BFF może być oddzielnym produktem tam, oddzielnie rozwijanym.

Szymon Warda: Tak, ale też idąc tym może też być na osobnym hoście, bo jeżeli dany partner, dany nasz frontend ma inne SLA, to tylko jemu podbijamy i w tym momencie płacimy finalnie mniej. Więc naprawdę, jeżeli mamy API Gateway’e, powinniśmy mieć API Gateway’e, to wprowadzanie BFF-ów dla mnie staje się już w tym momencie koniecznością. To ma sens.

Łukasz Kałużny: Tak. Ma to sens.

Szymon Warda: Dobra, to kończymy.

Łukasz Kałużny: Na razie.

Szymon Warda: Na razie.