Patoarchitekci wracają z nowym shortem! Sprawdźcie, co nowego u Netflixa, dlaczego nawet dziś warto znać etagi http… oraz co nieco o dojrzałości API !
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
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/80. Albo link gdzieś tu na dole pod filmikiem, gdzie słuchacie.
Szymon Warda: Jakbyście nie zauważyli, to nagrywamy dzisiaj trochę wcześniej niż normalnie, także. Dobra, to jak już chciałem to zacznę. Dwa wpisy z Netflixa, całkiem niezłe odnośnie ich migracji z API i co ważne API wykorzystywanego przez frontendy i łącznie z aplikacjami mobilnymi. To jest super ważne, bo wydawanie stron jest dużo łatwiejsze, wydawanie rzeczy mobilnych, dłużej się to ciągnie wszystko tak naprawdę. Cele wpisów - nie są do przeczytania. Tak naprawdę. Co oni zrobili? Mieli jeden monolit, który obsługiwał, korzystając jeszcze z ich własnego mechanizmu dostarczania API, obsługiwał wszystkie API de facto, czyli taki centralny punkt. Nie najładniej. I przeszli na sfederowanego GraphQLa.
Łukasz Kałużny: Wiesz co, Szymon. Ale jedna rzecz.
Szymon Warda: No.
Łukasz Kałużny: Netflix po tylu latach działania - to jest tam bodajże 2020 zaczęli przechodzić na GraphQLa z monolitycznego API. Zobacz przy jakiej skali rozwoju produktu z iloma funkcjonalnościami dobili do tego, że muszą przejść na GraphQLa.
Szymon Warda: Bo ten ich engine, on jest GraphQLowy, on wygląda jak GraphQL, oni stwierdzili, że rozbijają się w ogóle na… Są dwie rzeczy ważne - rozbijają monolit i przechodzą na standard rynkowy. Nie trzymają własnego. To są takie dwie dość ważne… Przy czym ten drugi punkt jest kompletnie w tym artykule omijany. Kiedyś Netflix napisał właśnie czemu w ogóle przez GraphQLa - a ze swojego schodzą. Jak oni to zrobili? Zrobili fazy pierwsze i zrobili shima po prostu, w którym komunikował się Monolit, żeby w ogóle nauczyć się jak GraphQLa podejść, jakich klientów mieć i tak dalej i tak dalej. Bardzo fajne podejście, bo to się przydaje. Nie ma co robić husaria bo zadziała, aaa dobrze będzie. I potem zaczęli wywalać de facto tego shima.
Łukasz Kałużny: Wiesz co, jeszcze jedna rzecz, bo shim, bo niektórzy zawsze mają z tym problem. My też często używamy tego słowa jako shim. Normalnie to jest, powstało gdzieś w starych latach do tego, że przerabialiśmy jakąś bibliotekę, która udawała jakieś API, a pod spodem przekierowywała się na coś nowego, albo zmieniała po prostu ten data flow w bibliotece, więc to jest istotne. Więc w tym wypadku shim jest tutaj taką nakładką, która ma dać stare API, a tutaj albo starą funkcjonalność tutaj przekierować.
Szymon Warda: Taka wydmuszka de facto, zmieniająca trochę zachowania, nie dodająca nic od siebie. A po to właśnie zrobili… Przechodzili na swojego GraphQLa. Ten fragment artykułu jest średni, powiedzmy sobie. Ale co jest fajnie opisane i co jest dla mnie wartością tego artykułu. To jest jak testowali, bo artykuł w ogóle jest w dwóch częściach tak naprawdę. Druga część jest bardziej o testowaniu, testy funkcjonalne, niefunkcjonalne. Inaczej podchodzili do testowania Requestów, które są idepodentne, czyli można wykonać je wiele razy, bo tu zrobili po prostu replay Requestów tak naprawdę i to jest fajne podejście. Robili testy A/B. To jest dość sensowne, ale co jest ważne w testach A/B. Ponieważ testowanie na poziomie samego Requestu to jest jedna rzecz, on się zachowuje tak samo. Jeżeli chodzi o Requesty, które jednak jakieś zmiany wprowadzają, ale oni zrobili jeszcze jedna fajną rzecz. Sticky canary. Czyli jeżeli generalnie użytkownik trafił sobie do jednego z API GraphQLowego albo starego, to przez całą swoją sesję był na jednym API. Czemu? Bo niektóre procesy typu oglądanie, typu cała latencja jak to w ogóle wpływa na user experience czy nie patrzenie tylko na scope jednego requestu, ale patrzenie na cały flow i całe zachowanie naszego użytkownika, konsumenta, API, nie.
Szymon Warda: I to jest bardzo fajny punkt z tego artykułu wynika.
Łukasz Kałużny: Raczej tak, to jest też takie uproszczenie, że zróbmy sobie canary na poziomie infry, a de facto jest to bardziej skomplikowane i to fajnie przedstawia ten problem A/B Testingu Canary Releasów. Ogólnie, że powinniśmy podchodzić tak, że jak już tam użytkownika wrzuciliśmy to niech on na tym testuje, a nie że pójdzie gdzieś tam losowo z requestem.
Szymon Warda: Ja bym wziął tak, że pierwszy etap Canary to jest taki, że wrzucamy losowo, bo jak będzie wtopa, to żeby przynajmniej nie było problemu z przełączeniem, a potem jak dalej wdrażamy coś większego to najwyżej faktycznie musimy całe flow zobaczyć. No ale canary releasy się przydają bardzo mocno i faktycznie podejście do tego właśnie Sticky Canary dobrze opisali, więc no warte do rzucenia okiem. Co tam Ty masz, Łukaszu?
Łukasz Kałużny: Dobra, tak z bloga Martina Fowlera, ale klasycznie nie pisał tego Martin Fowler. Jak to jest? Zaczął być thoughtworksowym miejscem do publikacji, jego blog po prostu i jest sobie wpisik trochę powiązany, nawet można powiedzieć z Twoim. Linking Modular Architecture to Development Teams. Jest tutaj jakieś case study, nie jest podany klient na temat podejścia de facto do… Jak podzielić zespoły, aplikacje i funkcjonalności, żeby nie wchodziły sobie w drogę i mogły to rozwijać równolegle. I są tutaj przedstawione różne rodzaje, de facto trochę patrząc się z poziomu DDD. Są przedstawione różne rodzaje podejścia do tego, jak to właśnie ułożyć. Czyli z jednej strony jest tam klasyczny model, z drugiej strony model ułożenia jako next market opportunity, czyli w zależności gdzieś od rynków czy innym - podejście właśnie, że mamy wyznaczone domeny i np. jeżeli mamy wiele krajów tak jak w tym przypadku pokazanym, dane ficzery są w danej wersji wybierane, a zespoły robią to całościowo. Jest to dość obszerny wpis pokazujący jakieś ich wyniki w przypadku tej appki mobilnej i tak jak porównali to z takich tych… Jeżeli chodziło o integrację to Average Development Time rzekomo spadł im z 90 dni do pięciu.
Szymon Warda: To jest bardzo duża różnica.
Łukasz Kałużny: Tak, jest taka - dobra, gdzie to jest? Chociaż z drugiej strony jak pomyślisz, że zaczynasz wycinać małe funkcjonalności i zespołom dawać, nie przebijać się przez jakiś kawałek monolitu i innej rzeczy, to nagle jest to pewnym prostsze, bo zazwyczaj integracje robisz z jakąś funkcjonalnością, a nie z całością.
Szymon Warda: Wiesz co? Jak słyszę takie straszne różnice to mi się zawsze pali taka lampka, że mówią, ooo, to wszystko jest z jednego powodu, mówię tak, eee, to z reguły jest złożenie powodów. Fajnie…
Łukasz Kałużny: Raczej wiesz co, wysprzątali.
Szymon Warda: Możliwe, że tak, ale fajnie, że na starcie artykułu oni wspominają, czemu to zrobili? Żeby obniżyć ten cognitive load, ten nacisk zespołów, to co mówiliśmy nawet odnośnie metryk zespołów parę odcinków temu tak naprawdę.
Łukasz Kałużny: Tak, o Developer Experience.
Szymon Warda: Dokładnie, bo to jest ważne, de facto nie będziemy wymagali od tych ludzi, żeby ogarniali wszystko i nic. To nie da rady po prostu tak długo ciągnąć.
Łukasz Kałużny: Raczej są osoby, które lubią dużo domen, ale jest to mniejszość!
Szymon Warda: Tak, tylko pytanie… Czy jak mając tą wiedzę o wielu domenach de facto będziesz miał głęboką wiedzę o wielu domenach - w sensie, to są, że potrzebujesz różnych ludzi w organizacji, ludzi, którzy mają szeroki pogląd o wszystkim, żeby wiedzieć co z czym połączyć, i ludzi, którzy są ekspertami w konkretnej domenie.
Łukasz Kałużny: Raczej generaliści plus specjaliści, to zawsze będzie musiało iść w parze.
Szymon Warda: Tak, dokładnie, post-integracyjnie generaliści są dużo lepsi. Specjaliści jeżeli chodzi o rozwój wewnętrzny. Tak naprawdę się spisują po prostu lepiej. Tak, ale właśnie jak powiedziałeś wpisik… To mi to nie grało, bo nie jest wcale taki mały.
Łukasz Kałużny: Tak, ja wiem, że nie jest mały. Jest to kawałek porządnego wpisu. O tak, Jeżeli ktoś podchodzi do całości układania, rozwoju produktu, większej aplikacji, to jest to taką ciekawą rzeczą, którą można przełożyć na inne obszary.
Szymon Warda: Znaczy, to nie jest nic jakoś super odkrywczego, ale to jest ładne ułożenie tego, co wiemy i taka nie wiem, dupoklejka, w sensie coś, co można dołączyć do maila, i zobaczyć - ok, bo to chcemy zrobić. Zobacz, tak to się robi.
Łukasz Kałużny: Tak - Ale jest krótsze niż jak całość i jest krótsze niż np. całe podejście platformowe i wysyłanie książki. Tylko tu jest tak o software developmencie, a nie o układaniu wszystkiego. Dlatego mówię - zazwyczaj nie lubię linkować do tego bloga, ale treść jest tutaj naprawdę okej, jest wartościowa.
Szymon Warda: Zgodziłbym się.
Szymon Warda: Jest niezły… dobrze. To teraz ja się wcisnę, co tutaj jest dalej - wpis odnośnie API Maturity Model - wpis ma swoje plusy, ma swoje minusy, nie jest jakiś super idealny, ale jest fajny do przemyślenia. Parę punktów robi dobrych, ponownie. O co chodzi? Chodzi o to, że poziom dojrzałości API został podzielony tak trochę książkowo na takie 4 poziomy. Pierwszy taki Dark Ages można powiedzieć, mocno nazywany - i tu wiesz fajnie, z czego wynika? Bo to nie jest to, że to jest ważne to, nie jest to, że klasyfikujemy API. To jest to, że proces dojrzałości API no nie? Co jest też ważne. Czego on trochę nie zaznacza w tym modelu to jest to, że nie każde API musi być na tym najwyższym poziomie dojrzałości, do którego za chwilę dojdziemy. Jest Dark Age, czyli generalnie budujemy API wokół dorwania się do danych tak naprawdę i tam ogarniamy skarby i to takie bardzo proste rzeczy.
Łukasz Kałużny: Tak. Przy czym też z drugiej strony ten pierwszy poziom - i on jest, dla wielu osób będzie wystarczający, bo jest ten punkt, który mi tutaj się. Te 4 punkty, które są wyróżnione w tym poziomie, czyli projektowanie API po to, żeby były łatwe w integracji, reużywalne, żeby mieć to z tyłu głowy, tworzenie spójnych interfejsów, wersjonowanie czy gdzieś tam niby scalability, to wyrzućmy ten bullet, ale dobrze pokazuje, że to jest taki pierwszy poziom naprawdę dojrzałości.
Szymon Warda: Tak, dlatego nazwy takie książkowe, bo tam są takie problemy, będziemy wchodzić za chwilę w temat renesansu i tak dalej. Więc nazwy są trochę błędne i niejako nazwanie czegoś Dark Ages nie do końca dobrze się kojarzy. Ale zgodzę się z tym właśnie, że ten pierwszy poziom w większości sytuacji wystarczy. Potem idziemy poziom drugi.
Łukasz Kałużny: Przepraszam, dodam jednego minusa odnośnie całego wpisu. Jest tu mało rzeczy na temat bezpieczeństwa, czyli w pierwszym wpisie brakuje mi tutaj. Dla mnie jakakolwiek dojrzałość zaczyna się z tym, że zaczynamy patrzeć na bezpieczeństwo.
Szymon Warda: Daj temu chwilę, bo dojdziemy do tego. Wydaje mi się akurat, że dlatego zaczęliśmy to wogóle omawiać przed nagraniem, że dobre umiejscowienie jest security - jeżeli o to chodzi, bo zobacz, w pierwszym jest ten Dark Ages, potem jest renesans, czyli dzielimy to API na komponenty, co też w sumie ma sens tak naprawdę, że czasami jak robimy usługę to lepiej po prostu, żeby to było w jednym i po prostu będzie łatwiej, no bo to dalej, odkrywamy - jak to API ma wyglądać. Poziom trzeci, oświecenie. Te dwie fazy są takie trochę rozmyte, tak naprawdę, ale w tym momencie adresujemy deployment, co jest trochę dziwne, że dopiero w tym momencie. Performance, security w tym momencie adresujemy jeżeli o to chodzi, ale taki bardziej, że patrzymy jak to w ogóle wygląda i potem automatyzację. Trochę to mimo wszystko późno i patrzymy bardziej na taki experience pod kątem. I to jest dość ważne, co rozróżnia tę frazę, to jest to, że patrzymy na API nie jako clouty do danych, tylko patrzymy na API jako coś co wspiera use case’y, workflowy, który występują w aplikacji i to jest kluczowe de facto.
Szymon Warda: To jest faktycznie w fajny sposób myślenie, że okej nie są to a to ten endpoint daje nam dane jakieś tam, tylko po prostu budujemy tak, żeby one wspierały całość, żeby jednak nie opierać na tym zbyt dużo. I czwarty poziom - wolność można powiedzieć właściwie tak naprawdę. I to jest. Dlatego właśnie mówię, że to dopiero sensowne, bo w tym momencie tu dopiero wchodzimy dopiero w eksternalizację. I to jest clou tego artykułu, że de facto masę z tych rzeczy warto robić, raczej inaczej, że dopiero w tym momencie, to są rzeczy zewnętrzne. I dla mnie właśnie w tym kroku się sugeruje zrobienie Governance, Observability i zrobienie całego systemu czyli portalu, itd. I dla mnie to w dużej mierze ma sens tak naprawdę, właśnie mówisz, że security trochę brakuje. Tak, że jest API totalnie wewnętrzne, wewnętrzne. W pierwszej, drugiej fazie ja bym powiedział tak - ja bym się nie skupiał na tym za bardzo.
Łukasz Kałużny: Znaczy wiesz co? Skupianie się to jest jedno, a zachowanie takiego wiesz minimum zdroworozsądkowego to jest duże. Zauważ, że przykładowo przepraszam jeżeli kogoś obrażę, ale już jak taki przykładowy menadżer to przeczyta i nie zobaczy, że przy takim, że powinienem jednak pamiętać, tylko jest dalej, to też lećmy sobie i używajmy tego i nie przejmujmy się.
Szymon Warda: Znaczy nie, to to jest artykuł wybitnie kierowany do osób technicznych z takim można się zgodzić, to nie są obszary, które olewamy. Ale to nie są security. Póki nie dajemy tego zewnętrznie przez zewnętrzne to nie musi być na rzecz firmy, to może być też zewnętrznie, między innymi działami itd. To możemy pomyśleć, bo podejście, które robi platformę to jednak musi być bezpieczna. Co mi się tu podoba w tym opisie, przede wszystkim… To, że patrzymy na - pierwsza faza jest spoko i że w pierwszej fazie mimo wszystko myślimy właśnie, między innymi o wersjonowaniu. Co w tym momencie ma sens, to jest to, że w tej trzeciej fazie enlightenment, sobie myślimy o tym, że patrzymy na API z punktu widzenia przypadków użycia to jest to, że w pierwszej fazie używamy tego i dopiero ucząc się - jak to API wygląda, jak konsumenci rozmawiają, że wykorzystujemy. Mam bardzo mieszane uczucia odnośnie tego, żeby dopiero w fazie czwartej robić Observability.
Łukasz Kałużny: Przecież to jest też, że powiedzmy sobie teraz tak - w zależności jaki typ Observability. Jeżeli mówimy o całym distributed to jest to w dobrym. Jeżeli mówimy o podstawowym to też powinna być o wiele wcześniej.
Szymon Warda: Tak, znaczy to minimum, to jest nawet w fazie pierwszej. Przekazywanie tokenu to jest takie generalnie, że okej, przekazujemy dalej, żeby innym aplikacjom tego nie rozwalać, bo to jest po prostu no brzydkie zachowanie. Jeżeli mamy cały tracing, wszystko fajnie i nie przekazujemy tokenu nagle.
Łukasz Kałużny: Wiesz co, ja zrobię sobie taką wrzutkę, bo z innych frameworków, które są do różnych dojrzałości ja mam taką preferencję, żeby używać 3-poziomowego… Słuchaj podejścia do nazywania, określania poziomów dojrzałości i jest taki sobie podział, że mamy initiated, czyli że w ogóle zaczęliśmy o tym myśleć. Czyli to jest ten level pierwszy, potem jest performed, czyli właśnie, że coś wykonujemy faktycznie. Czyli to jest te 2 i 3, które tak jak mówiłeś, że one są rozmyte pomiędzy sobą. I ostatni poziom, taki trzeci dojrzałości to jest manage. Kiedy faktycznie tym zarządzamy, mamy to uprocesowione. Potrafimy to obserwować i zmierzyć. Ja właśnie preferuję taki trójwarstwowy podział tej dojrzałości.
Szymon Warda: Ty mówisz o takiej, dojrzałości typowo wewnętrznej, a mam wrażenie że ten artykuł… On fajnie opisuje trochę co jest, on jest… Właśnie powiedzieliśmy, że on jest dla technicznych. Nie, wydaje mi się, że to jest dobry artykuł, wiesz dla kogo? Dla Product Ownerów. Żeby myśleć właśnie, bo potem on dalej fajnie wchodzi w tą opcję… Jak zbierać wymagania, jak zbierać taki commitment wokół całości i jak tą organizację przesuwać na to API? Więc wydaje mi się, że to jest dobry taki właśnie wpis dla team leaderów, architektów, ale też dla POsów tak naprawdę, żeby oni też wiedzieli jak w ogóle… Bo POsi często umieją zarządzać produktem jako takim. Ale jeżeli produktem jest API, to jest to trudniejsze. Dużo, no nie, bo tam nie zrobisz bo to UI i tak dalej. Więc to jest dobre podejście na zasadzie, okej. Jak do tego kawałka podejść?
Łukasz Kałużny: Dobra, teraz ode mnie taki jeszcze jeden mały wpisik kończący, czyli przypomnienie sobie czym są w http etagi…
Szymon Warda: Właśnie widziałem, że wygrzebałeś takiego starocia, że taki temat stary jak nie wiem co!
Łukasz Kałużny: Stary, ale wiesz co?
Łukasz Kałużny: On wraca i to jest… Wiesz, też mi się to rzuciło. Wraca się. Też go w zeszłym tygodniu wspominałem przy prowadzeniu szkolenia. Musiałem też wspomnieć o tym, po co to w ogóle jest i widzę, że ta wiedza…
Szymon Warda: Ucieka.
Łukasz Kałużny: Używamy tego http, ale dużo osób nie ma świadomości, że wiele tam rzeczy pod spodem w tym protokole już od dawien dawna jest wyspecyfikowane i gotowe do użycia. I tutaj jest całość dość fajnie krótko opisana na temat czym są właśnie entity tagi, w jaki sposób zaadresować rozwiązywanie konfliktów. Kiedy chcemy, żeby coś zostało zapisane, kiedy nie, w jaki sposób patchować i czym te wszystkie nagłówki oznaczają. I taka rzecz, jeżeli ktoś z Was pracuje na jakichś rozproszonych bazach danych, Cosmos DB, jakiś storage’ach.
Szymon Warda: Cassandra.
Łukasz Kałużny: Tak, storage’ach i innych rzeczach to z tymi Cassandra, to z tymi e-tagami się zawsze spotkamy i last modified na poziomie protokołu.
Szymon Warda: To właśnie wrzucę generalnie, do czego właśnie e-tagi, do określenia właśnie czy chcemy wprowadzić zmianę? To jest mechanizm do optimistic concurrency tak naprawdę.
Łukasz Kałużny: Dokładnie.
Szymon Warda: Mówiąc bardzo prosto, bo tam mamy timestampa jakiegoś i mamy czasowniki czy mamy operacje wykonać, załóżmy? Czy jeżeli e-tag istniejący na bazie jest równy, mniejszy, większy i możemy swobodnie sterować. Coś co no istnieje i będzie istniało przy jakimkolwiek requeście http, bo się dane mogły zmienić tak naprawdę.
Łukasz Kałużny: Znaczy, ogólnie przy systemie gdzie mamy więcej niż jednego użytkownika pracującym na tym samym secie danych.
Szymon Warda: Tak dokładnie, dokładnie, ale właśnie głównie tu mówimy odnośnie http i wiele właśnie usług, jak wejdziemy. To wspiera, to co powiedziałeś natywnie.
Łukasz Kałużny: Pudełka.
Szymon Warda: Blob to wspiera. Bardzo fajnie też w wielu sytuacjach, także nie ma potrzeby z reguły reimplementacji tego od nowa.
Łukasz Kałużny: Więc na końcówkę z rzeczy technicznych polecamy chwilę przeczytać, jeżeli nie wiesz z czym się je właśnie etagi, jest dobry początek, żeby to przeczytać. O co w tym chodzi?
Szymon Warda: Wpis jest krótki, jest bardzo krótki, naprawdę. Jest to napisane, nawet na poziomie bulletów, wyszczególnia to, co powinien.
Łukasz Kałużny: Takm na przykład last modified - if unmodified scenes, if modified scenes. Jak z konfliktem? Co tam jest, 412, 409… Wytłumaczone te statusy, które rzadko widzimy i w jaki sposób możemy do tego podejść?
Szymon Warda: Tak, przy czym one mogą się różnić w zależności od implementacji, ale warto wiedzieć co jest nad nią.
Łukasz Kałużny: Może takie - tu są bardziej w odniesieniu do RFC, bo na to RFC czekajcie, jeszcze sprawdzę tak na koniec z kiedy ono jest.
Szymon Warda: Stare będzie, jak nie wiem co, z brodą.
Łukasz Kałużny: Czekaj, no nie, te RFC jest akurat, te ostatnie z 2014.
Szymon Warda: Czyli z brodą, Łukasz, to już jest z brodą.
Łukasz Kałużny: Czekaj, ale jest ten… Trzeba było by sprawdzić, kiedy ten… Jeszcze wcześniejsze się pojawiło. Dobra, to chyba kończymy.
Szymon Warda: Kończymy. Na razie.
Łukasz Kałużny: Na razie. Hej!