Szymon Warda: Cześć! Słuchacie Patoarchitektów. Prowadzą Szymon Warda…

Łukasz Kałużny: I Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na Patoarchitekci.io/18. Dobra Szymonie, to o czym dziś?

Szymon Warda: Temat dzisiejszego odcinka da Łukasz Kurzyniec na uservoice na GitHubie. Oczywiście link do samego uservoice będzie w opisie odcinka, a będzie o API Gateway.

Łukasz Kałużny: Tak, Łukasz prosił troszeczkę o jeden ze wzorców wykorzystania, ale pierw warto wprowadzić API Gatewaye, bo w sumie jeszcze ich tutaj nie było.

Szymon Warda: Tak, dokładnie, a to jest dość spory kawałek. Ale zacznijmy od linków. Co u Ciebie?

Łukasz Kałużny: Wpis, który teraz wpadł na temat wydajności HTTP2, jak wygląda tam równoległość, jak wygląda serwer push dla restowego API. I warto zobaczyć, bo jest pokazane tak naprawdę od 1.1 do gdzieś dwójki, trójki razem z server pushem i pokazane na fajnych przykładach, bo skrypty są wykonywane na stronie, razem z wpisem są wykonywane skrypty javascriptowe pokazujące prędkość API. I stary trik, który używaliśmy z 1.1, żeby skleić te zapytania, czyli wykorzystać właśnie jakieś agregation, GraphQL-e, jest nadal najszybszym sposobem.

Szymon Warda: Tak, faktycznie. Dorzucę to, że wizualizacja tego jest naprawdę niezła i jakby ktoś chciał przekonać swoich developerów to niezłe narzędzie, pokazuje spore różnice.

Łukasz Kałużny: Tak i warto odpalić sobie tryb developerski, zobaczyć jak te requesty lecą razem z tym, co się zmienia na ekranie i nam pokazuje.

Szymon Warda: Tak.

Łukasz Kałużny: Dobra, a co u Ciebie?

Szymon Warda: Ja kawałek o architekturze tfu tfu mikroserwisów. Ale wpis dość ciekawy generalnie, bo zacznę od tego, że etap dalej po mikroserwisach, czyli przejście na strumienie, przejście na taką architekturę właśnie eventową, całkiem ciekawa prezentacja na InfoQ, jak to często u mnie bywa, która właśnie daje takie ogólne podejście, co dalej poza mikroserwisami, gdzie możemy pójść i jak też duże właśnie systemy z naciskiem na strumienie podchodzą, na przykładzie Kafki akurat.

Łukasz Kałużny: Powiedziałeś właśnie o stanach i o strumieniach. To jest też ciekawe, że ten event-driven też są stanowe.

Szymon Warda: Oczywiście, że są. Dane musimy gdzieś w końcu trzymać generalnie.

Łukasz Kałużny: Więc to jest ciekawe. Też będę musiał sobie to zobaczyć, bo tak jest trochę buzzwordów, zobaczymy jak to zostało sklejone.

Szymon Warda: Tak. Dobra, to zacznijmy w dwóch zdaniach Łukaszu, czym jest API Gateway?

Łukasz Kałużny: Najprościej? Wspólny interfejs sieciowy dla usługi, dla grupy usług. Można też powiedzieć, że to jest taka sieciowa implementacja wzorca fasady.

Szymon Warda: No to jest taki makijaż, który się nakłada na system, żeby ładnie wyglądał, mimo że on już jest po 10 czy 15 operacjach plastycznych tudzież architektach, którzy mieli różne pomysły na niego.

Łukasz Kałużny: Wiesz co, mógłbym powiedzieć, że tak i nie. Często się tak kończy, że chowamy tam swój cały, że tak powiem, bałagan, który posiadamy, w szczególności przy mikroserwisach. Ale jeżeli na to popatrzeć, to pod tym pojęciem kryje się trochę rzeczy. Jak sobie popatrzymy na samo pojęcie API Gateway’a, to tam już pod spodem możemy teraz wyróżnić kilka typów. I będzie taki najprostszy, który jest tak na prawdę API proxy albo niektórzy nazywają to Application Delivery Controlerem, tak jak nazywa to F5. Możemy wyróżnić potem ten z większą ilością logiki API Gateway i na koniec Enterprise API Gateway. Czyli już teraz możemy rozróżnić sobie podtypy tego.

Szymon Warda: Ja też, żeby nie było, nie mówię, że ten cały makijaż jest zły, tylko dochodzimy do tego, że w API Gateway i szczególnie w API Gateway i Enterprise API Gateway ląduje kod, którego nie chcemy mieć albo nie możemy mieć w innych miejscach systemu, na przykład jak mówiłeś o mikroserwisach. Ale też to są systemy, które określane są jako stare systemy i wystawiamy je w nowej formie na świat. Dlatego wsłaśnie to odmalowanie jest jak najbardziej. Dobrze, uporządkujmy to. Od pierwszego, API proxy, znowu w dwóch zdaniach.

Łukasz Kałużny: Znowu? Dobra, API proxy to będzie takie w cudzysłowiu proste chowanie usług za jednym wspólnym endpointem, interfejsem. Po prostu taka brama wejściowa, reverse proxy do naszego systemu.

Szymon Warda: Tak, czyli służy nam głównie do tego, żeby powiedzieć, które URL-e są dostępne, a które nie są dostępne. No bo całych maszyn wirtualnych z naszym serwisem nie chcemy wystawiać, tylko chcemy poszczególne URL-e i to do tego głównie służy.

Łukasz Kałużny: Tak, wystawianie swoichch właśnie, wyroutowanie tego. Tak można to najprościej opisać. I jeżeli sobie popatrzymy od razu na przykłady tego API proxy, bo mamy tą prostą logikę i to jest jakieś nginxy, HAProxy, F5, jeżeli mówimy często w on premie w dużych organizacjach. Jeżeli korzystamy z mikroserwisów na Kubernetesie to będzie od razu Ingres kontrolery, które są tam różnej maści i właśnie one pozwalają nam to w prosty sposób schować i udostępnić to w organizacji czy na świat, jeżeli mówimy o jakimś kliencie webowym, jakimś kliencie mobilnym. Jak popatrzymy na funkcjonalności, gdybyśmy mieli wyróżnić, to taka podstawowa to będzie host i path routing, bo większość teraz nowych API to są jakieś wariacje na temat, budowane na bazie HTTP, więc taki API proxy to rozumie. Może też czasem sprawdzać tokeny, nagłówki, ale bez większej logiki. No i oczywiście całe zabawy z certyfikatami, z przepisaniem certyfikatu, zmianą, zrobieniem end to end to SSL, offloadingu, jeżeli w środku nie musimy mieć SSL-a. Więc całą maści tej rzeczy.

Szymon Warda: Tak, dotknąłeś ważnego bardzo obszaru, bo powiedziałeś, że prostej logiki. Jak ja to często doprecyzowuję, to jest to, że na tym poziomie rozumiemy http, taki prosty bardzo http, ale nie rozumiemy treści, co jest tym http. Czyli rozumiemy headery, rozumiemy URL-e, cookiesy, czasami może się zdarzyć w sensie czy jest czy nie ma cookiesa, ale to jest bardzo prosta logika tak naprawdę, nie wnikamy w to, co jest głębiej.

Łukasz Kałużny: Tak, mimo, że rozwiązania które wymieniłem na to pozwalają, to nie wnikamy w zawartość w samym podejściu, jeżeli mówimy o API proxy.

Szymon Warda: Dobrze, to teraz pójdźmy krok dalej, API Gateway. Znowu dwa zdania.

Łukasz Kałużny: Wiesz co, tak, API Gateway lub też mikroserwisowe API Gateway, bo trzeba to połączyć. Jeżeli to rozszerzymy, to tak naprawdę są to rozwiązania, które rozumieją treść naszych requestów i pozwalają na nich operować w przeciwieństwie właśnie do API proxy. Czyli możemy się tam zagłębić.

Szymon Warda: I teraz dotykamy bardzo śliskiego gruntu. Mianowicie dotknąłeś tego zdania magicznego: rozumieją requesty i mogą na nich operować. Czyli to bardzo łatwo może spowodować, że w takim razie możemy zrobić wszystko i wracamy do ESB i pierdolnika i tam logikę wrzucamy. Nie. Wyszczególnijmy może, czemu potrzebne nam jest to rozumienie, do jakich funkcjonalności?

Łukasz Kałużny: Wiesz co, jeżeli popatrzymy się, dobrze, że powiedziałeś o ESB, API Gateway to nie jest ESB i trzeba się tego wystrzegać. O tak, to jest taka bardzo ważna rzecz. I to pozwala nam, całe to rozumienie pozwala nam implementować różne wzorce aplikacyjne na wejściu do naszego systemu. To jest właśnie istotne, że na wejściu, pozwalając innym skorzystać z niego. I możemy też powiedzieć tutaj o centralnym miejscu dla security, kiedy udostępniamy, żeby wyrzucić dużą część z samych usług, z naszych aplikacji. Jak mamy to wymienić? No to będzie to, zacznę tutaj throttlingi dostępu do naszej aplikacji, cache’owanie requestów, bo być może mamy rzeczy, które chcemy scache’ować już na wejściu i wiemy jak to zrobić na podstawie tego co jest w zapytaniu. Circuit breakery, http retry’e, które można w środku od razu ogarnąć, translację, jeżeli tego potrzebujemy. Jednym z takich przykładów bardzo często używanych jest zrobienie http API z jakiegoś soapowego czy na odwrót, żeby udostępnić w prosty sposób, bez zabawy już na samej usłudze. Przy tym zmiany właśnie protokołów przy tej translacji czy gateway agregation, kiedy chcemy połączyć wiele rzeczy.

Szymon Warda: Tak. Ja od siebie bym dorzucił, że tu jeszcze jest parę rzeczy, gdzie wykorzystujemy. To jest wprowadzenie, jak chcemy wprowadzić politykę wersjonowania API. Czyli mamy już serwisy w różnych wersjach, chcemy zostawić jedną wspólną wersję. Dokładnie jak do tego podejść będziemy mówili w kolejnym odcinku, taki hint mały. Co jeszcze dalej jest? Wprowadzenie kontraktów jawnych dla naszego całego API, Swagger na całość.

Łukasz Kałużny: Tak, jest to istotne, że możemy w łatwy sposób wygenerować spójny cały kontrakt.

Szymon Warda: Tak. Jeszcze zastosowanie, które ja też bardzo lubię, to jest jak mamy systemy wielotenantowe. Czylimamy jedną aplikację, z której korzysta wiele firm, usług, podmiotów, to na poziomie właśnie API Gateway możemy robić routing, taki bardziej inteligentny. Czyli mamy ID klienta, i routujemy go do konkretnego serwera, do którego on, akurat tam jego dane się znajdują. I też fajna opcja, którą Ty wspomniałeś wcześniej, czyli interface mocking. Czyli wystawiamy prosty interfejs na potrzeby na przykład frontendu i on po prostu zwraca plik, zawartość pliku, a my sobie tam w tle developujemy to i to się bada.

Łukasz Kałużny: Tak, ale za ten inteligentny routing to po prostu powinieneś dostać nagrodę, bo trudno go nie mieć jak mamy translację i zmiany protokołów. Ja jeszcze…

Szymon Warda: Ja nie dam rady?

Łukasz Kałużny: Tak, dorzucę od siebie jeszcze security, o którym wcześniej wspomniałem, bo to też jest istotna rzecz w przypadku API Gatewayów, że możemy tam opędzić wszystkie zabawy z uwierzytelnianiem certyfikatami. Możemy zrobić porządek z tokenami JWT, zwalidować, zobaczyć, czy możemy w ogóle przekierować taką osobę, takie żądanie do danej usługi, czyli całe Out OpenID Connecty. W niektórych przypadkach da się zrobić uwierzytelnianie, czyli wziąć, uwierzytelnić tego człowieka i na przykład doklejać mu token, jeżeli mamy pod spodem tokeny, a na zewnątrz nie chcemy, więc można tam wprowadzić dużo takiej logiki technicznej.

Szymon Warda: Tak, na przykład tłumaczenie w ogóle logiki właśnie autoryzacji między systemem zewnętrznym i wewnętrznym, też to jest popularne.

Łukasz Kałużny: Tak, trzeba chyba tylko jedno uważać, że można dużo łatwo zrobić tej logiki właśnie, żebyśmy nie skończyli o to ESB, od którego uciekaliśmy w przypadku monolitów i SOA.

Szymon Warda: Tak i tu jest dla mnie prosta definicja. API Gateway jako taki może mieć kroki techniczne i niebiznesowe. Jaka jest różnica? Ta granica między techniczną a biznesową często jest rozmyta. A dla mnie jest prosta, tak naprawdę można to zdefiniować. Jeżeli tak naprawdę system w tym momencie ma krok procesu biznesowego w sobie, to to nie powinno być w API Gateway’u, że to jest krok jakiś tam wstępna walidacja, taka już biznesowa, tam się nie powinno to znaleźć, bo to jest śliski grunt i za chwilę będzie tam wielki pierdolnik.

Łukasz Kałużny: Czy wiesz co, właśnie powiedziałeś o tym pierdolniku. Ale mi też… Miałem, czasami popełniłem to bardzo świadomie, że część troszkę logiki biznesowej została przeniesiona do API Gatewaya. I to było policzone ryzyko, że robimy to w API Gateway’u. I zadanie, które miałem w paru przypadkach to było: posiadamy na przykład stare WSDL-owe API, a pod spodem wymieniamy cały system i usuwamy wszystko i nie chcemy mieć tego WSDL-a. I na przykład jedno takie zapytanie, które jest typowo komendą WSDL-ową, trzeba rozbić czasem na kilka restowych requestów i podjąć decyzję co, gdzie, jak uderzyć. Więc czasem jest to dobre miejsce, ale czasem, to też nie warto tego od razu myśleć. Więc pierwsze to negujemy, a potem się zastanawiamy, bo łatwiej często będzie utrzymać to w kodzie.

Szymon Warda: Doszedłeś do jednej ważnej rzeczy, że API Gateway jest super miejscem, żeby takie rzeczy wprowadzić, ale to nie jest miejsce, gdzie te rzeczy powinny długo żyć. Bo finalnie generalnie dzięki właśnie API Gateway osiągnąłeś tą łatwą wersję translacji między wewnętrzną logiką aplikacji i architekturą, a zewnętrznym światem. Ale finalnie co powiedziałeś, łatwiej będzie to utrzymać w logice aplikacji czy w jakimś kodzie po prostu.

Łukasz Kałużny: Tak, w wielu przypadkach kod będzie na koniec dnia przy modelu operacyjnym będzie dla nas prostszy.

Szymon Warda: Tak, znaczy to co mówiliśmy, API Gateway to jest takie miejsce, gdzie trzymamy cały kod, który nie wiemy gdzie trzymać albo nie mamy gdzie trzymać. Po prostu.

Łukasz Kałużny: Tak, trochę mi serverlessem zaleciało.

Szymon Warda: No tak to bywa. Ale rzućmy jakimiś przykładami implementacyjnymi. Co mamy w ogóle produktowo w API Gateway’ach?

Łukasz Kałużny: Wiesz co, produktowo jest tego naprawdę dużo. I po pierwsze trzeba… Każdy cloud ma to praktycznie jako usługę. I najlepiej tutaj z mojego doświadczenia wypadają, jeżeli popatrzymy na tych cloudowych dostawców, dwie usługi. To będzie Apigee, który jest w Google’u i Azure API Management. I co ważne, one też tam w jakiś sposób już schodzą albo już są do trybu takiego self-hosted i on premu, gdzie możemy to samą taką bramę posadzić w swoim rozwiązaniu, ona będzie zarządzana jak as-a-service, ale sama instancja będzie hostowana u nas głównie na bazie gotowych już kontenerów. To jest jedno. I druga część, to będzie taka self-hosted on premises. I tu też możemy tego dużo wyróżnić. Z takich popularnych będzie to CONC TAPI dla świata .Netowego, Ocelot, który jest, dla świata Javowego znowu Spring Cloud Gateway, który jest gotowym rozwiązaniem, które łatwo zaimplementować. No i każda firma od ESB tak naprawdę posiada teraz jakiś produkt do robienia API Gateway’a.

Szymon Warda: Przemalowanie starego produktu.

Łukasz Kałużny: Tak, niektóre były przypisane, ale tak, jest to. I teraz jeszcze taka ciekawostka, bo wcześniej wspomniałem na przykład o nginx’ie i oni też próbują powiedzieć, że są regularnym API Gatewayem, bo możemy tam dopisać kod w przypadku na przykład do, jako Lua i często się to znajduje w przykładach. Możemy dopisać…

Szymon Warda: Albo też moduł C.

Łukasz Kałużny: Tak, moduł C i oni też dają chyba jakieś swoje moduły do robienia takiego gateway’a. Ja osobiście nie przeglądałem, tylko dokumentacje, nie wchodziłem co jest w środku, ale dość mocno się promują jako, żeby nie zginąć w tym mikroserwisowym i serverlessowym świecie.

Szymon Warda: Dobra, ale teraz dochodzimy trochę do tego, że tak się trochę z tym nie zgodzę co powiedziałeś. Czemu? No bo tak naprawdę część usług, które wymieniłeś, to już tak bardziej zahaczają o Enterprise API Gateway, a część są API Gatewayem. I to teraz, żeby mówić o różnicach, to teraz doprecyzujmy jak Ty rozumiesz Enterprise API Gateway? Czym dla Ciebie jest?

Łukasz Kałużny: Enterprise API Gateway, to będzie koncept udostępniania API, ale na poziomie całej organizacji, nie tylko systemu. Tak można powiedzieć buzzwordowo, jak na to popatrzymy. To będzie coś, co od kilku lat się pojawia, czyli monetyzacja istniejących API lub tych nowych, które tworzymy. Czyli jest to od strony, czyli patrzymy na to od strony też biznesowej i całej logicznej na poziomie organizacji. I tak te produkty, które podałem, w szczególności te cloudowe, czyli Google Apigee, jak i Azure API Management, tak, to są Enterprise Gatewaye. Ale w przeciwieństwie do ESB to nie oznaczają ciężkich produktów, tylko można po prostu pewien zakres funkcjonalności wykorzystać do bycia API Gateway’em i wszystko będzie w porządku. Jak popatrzymy sobie na cenniki, to tam widać różnice nawet po funkcjach. Bo dla mnie Azure, to mamy tą wersję serverless, która jest biedna i ma dużo rzeczy wykrojonych od strony jakichś security translacji. Potem mamy standard, który potrafi dużo. A tak enterprise’owo potrafi tylko te najdroższe premium, więc jest zróżnicowanie tego, co potrzebujemy. Na tym można zobaczyć.

Szymon Warda: Tak, ale dla mnie też fajnie w kontekście organizacji pokazuje kto utrzymuje API Gateway, kod mianowicie i utrzymanie, całą logikę i tak dalej. Jeżeli mówiliśmy o tych pierwszych właśnie API proxy, API Gateway prosty, to z reguły utrzymywały zespoły odpowiedzialne za poszczególny system. Czyli tych gateway’i mogło być dużo. Był generalnie jeden presystem, ale systemów z reguły było dużo. A jak mówimy o Enterprise API Gateway, to z reguły to jest jedna na organizację usługa i to z reguły utrzymuje wydzielony osobny zespół.

Łukasz Kałużny: Gdzieś jest to wrzucone centralnie. Ja to widziałem na przykład, przyjmowały to albo w bardzo dużych organizacjach, to robiono mały zespół do tego, a w niektórych przyklejano tą rolę na przykład do zespołów od integracji jakichś, bo często występowały takowe, czasem od tych ESB, od zespołów ESB i próbowano budować nowe księstwo albo królestwa.

Szymon Warda: Tak. Ale teraz przejdźmy feature’ami generalnie. Bo skoro mówiłem, że się nie zgadzam z niektórymi, że niektóre są API Gateway’ami, które są Enterprise API Gatewayami. Przykład, Ocelot jest typowym API Gatewayem. To nie jest usługa, która będzie awansowana na Enterprise API Gateway. A taki Azure Management jest to typowy Enterprise API Gateway, który może być stosowany jak najbardziej jako API Gateway. To przejdźmy feature’ami, bo to definiuje, kiedy która usługa jest wykorzystywana. Które feature’y definiują API Enterprise, API Gateway?

Łukasz Kałużny: Dobra, to pierwsze to będzie bardzo mocno security. Bardzo rozbudowane security.

Szymon Warda: Tak.

Łukasz Kałużny: Tutaj obsługa wszystkich tokenów, kluczy, kluczy dostępowych, to jest bardzo istotna rzecz. Czyli security, ja będę stawiał to na pierwszym miejscu przy takim Enterprise API Gateway.

Szymon Warda: I też mocno tłumaczenie generalnie różnych typów security zewnętrznych na wewnętrzne.

Łukasz Kałużny: Tak, dlatego mówiłem właśnie, obsługa tych tokenów i te translacje, które za tym idą. I kolejną rzeczą, którą idzie, to jest self service portal, który taki produkt powinien posiadać, taki typowo developerski portal i dla naszego klienta, który będzie konsumował te dane. I to jest właśnie też istotna różnica, która to wyróżnia.

Szymon Warda: Konsumował, przeglądał, rozumiał i eksplorował i też przeglądał też cenniki, bo to jest taki portal, który sprzedaje nasze API, prezentuje i sprzedaje.

Łukasz Kałużny: Tak, więc to jest ta część. I tutaj trafiłeś do następnej rzeczy, czyli poza service portalem, to dochodzą nam właśnie subskrypcje, które na przykład mówią, że mamy jakiś tam throttling, mamy jakieś quoty, ilość requestów na miesiąc, czyli bandlujemy sobie nasze API, je udostępniamy.

Szymon Warda: I często też mamy monitoring tego, ile użyliśmy i jak to obecnie wygląda. To jest też ważny element.

Łukasz Kałużny: Tak i za tym idzie również billing API, czyli że rozliczamy. Powiedzieliśmy, że chcemy zarabiać, więc musimy na podstawie czegoś zafakturować i rozliczyć, jeżeli chcemy to robić naprawdę dynamicznie. I dochodzą billing API. Z tego co kojarzę, to nawet Azure’owy API Gateway posiada nawet jakieś integracje w stanach do płatności i fakturowania. Do tego stopnia jest to as-a-service akurat tam zamknięte, więc tutaj popatrzymy. Więc to jest też nastawienie na security i na tą monetyzację połączoną z self servicem.

Szymon Warda: Ładnie dochodzimy do tego, czemu powstało w ogóle Enterprise API Gateway. No bo firmy stwierdziły, że dane są warte, usługi też są warte i można na tych rzeczach zarabiać. To jest kolejny kanał sprzedażowy dla wielu firm, które zarabiają na tym tak naprawdę i zarabiają dość sporą kasę. Widzą, że nie produkty jako takie pudełkowe są wartością, tylko te dane, które mają o użytkownikach, o nas i usługi, rzeczy, które umieją zrobić.

Łukasz Kałużny: No tak, można rzucić, tego powstało teraz, nawet regulacyjnie powstaje masa, bo zobaczmy cały open banking, PSD2. Wcześniej jeszcze wokół finansówki i ubezpieczeń trochę takich API już od jakiegoś czasu istnieje.

Szymon Warda: Tak. Dobra, to chyba wrapujemy ten odcinek.

Łukasz Kałużny: Tak.

Szymon Warda: Na zasadzie zacznijmy… W ogóle jakie rady? Na starcie zacząć od zwykłego API proxy.

Łukasz Kałużny: Tak i tutaj się zgodzę. W szczególności teraz, dużo robimy na chmurze, serverlessach, albo na Kubernetesach. I tam mimo nawet jeżeli weźmiemy jakieś API Gateway, który jest as-a-service, to na początku traktujmy go tylko jako API proxy.

Szymon Warda: Tak i mieliśmy dyskusję w ogóle kiedy wprowadzać API Gateway. I po jakimś czasie udało nam się ustalić, że API Gateway wprowadzamy wtedy, kiedy chcemy pokazać nasze usługi innym developerom. Czyli kiedy nasze serwisy będą wykorzystywane przez innych ludzi poza nami bezpośrednio, naszym systemem. Wtedy wprowadzamy ładnie API Gateway’a.

Łukasz Kałużny: Tak, to jest właśnie istotne, że kiedy zaczynamy udostępniać poza naszego mobile, naszego weba, kiedy ktoś inny ma zacząć skorzystać nawet wewnątrz w organizacji. No i tutaj API Gateway jeżeli chodzi o security, czyli jak już chcemy to uspójnić, to walidację tokenów, autoryzacje. No i części trochę bardziej aplikacyjne wzorców, throttling czy circuit breaker, który tak Szymon kocha, bo można już w naszym API Gateway’u zaimplementować i wykorzystać tak naprawdę wbudowane możliwości do circuit breakera i obsługi tych requestów, zanim dojdą do tego.

Szymon Warda: Co jest bardzo ważnym właśnie przypadkiem? Kiedy ktoś inny korzysta z tego API, bo w tym momencie musimy wystawić SLA. Więc tak, to jest ważne. Dobra, no to w kolejnym odcinku o dobrych, złych i brzydkich praktykach.

Łukasz Kałużny: Tak, żeby nie przedłużać, to przejdziemy tam. I tam odpowiemy na pytanie Łukasza na temat Agregation Gateway’a i jak go stosować między innymi.

Szymon Warda: Dobra, no to tyle, na razie.

Łukasz Kałużny: Na razie.