Pojawienie się “super-puper” lekkiej biblioteki do formatowania daty skłoniło nas do dyskusji na temat mikro-bibliotek i czy na pewno dzięki nim nasze życie jest łatwiejsze. Rozprawiamy też o enkapuslacji i bibliotekach jako takich. Następnie przechodzimy do nowości w Apollo Client 3.0 i dlaczego szczególnie nas cieszy nowa wersja. Poświęcamy też chwileczkę, żeby podzielić się, a jakże, naszymi opiniami na temat GraphQL i Apollo.

Przydatne Linki

• LightDate: https://github.com/xxczaki/light-date
• LeftPad: https://www.npmjs.com/package/left-pad
• NPM & left-pad: Have We Forgotten How To Program?: https://www.davidhaney.io/npm-left-pad-have-we-forgotten-how-to-program/
• Apollo Client 3.0: https://www.apollographql.com/blog/announcing-the-release-of-apollo-client-3-0/

Transkrypt

Marek Piechut No więc, witaj Bratku. Jako że fanki narzekały, że w ostatnim odcinku niewiele mówiłeś, no to chciał bym żebyśmy zaczęli dzisiaj od Twojego tematu, może?

Bartek Witczak No dobrze, niech będę pierwszy…, miałem inny plan. Dobra, ja idę w temat bibliotek do dat. Jakiś czas temu była taka informacja, która pojawiła się w wielu newsletterach, odnośnie tego, że powstała nowa hiper, super, turbo szybka biblioteka do dat, która formatuje daty. No i z ciekawości zajrzałem, bo zastanawiałem się co to może być, myślałem, że to jakaś alternatywa dla Moment.js’a czy DateFNS’a. No i okazało się, że ta super, hiper szybka biblioteka, jedyne co robi, to formatuje daty. W sumie, to jeszcze ciekawe jest, że jeszcze oprócz tego było napisane, że jest lightweight, także, że można ją wszędzie wstawić i nie będzie dużego problemu. I ogólnie zacząłem się nad tym zastanawiać, bo wydaje mi się, że na początku JSa było takie podejście, że biblioteki, które tworzymy są takie małe, reużywalne, można sobie to dobierać do projektu wedle własnego uznania. Każdy weźmie to co potrzebuje, ale teraz mam trochę wrażenie, że wszystko musi być super, hiper fast, ultra turbo lightweight i konsekwencją jest to, że powstają biblioteki, które rzeczywiście robią nam tylko jedną rzecz, a suma sumarum potem musimy wybrać kolejne biblioteki, które poza tym, że nam sformatują tą datę to jeszcze nam ją sparsują albo wykonają jakieś operację w stylu: dodawanie czy odejmowanie dni, tygodni, miesięcy, bo jakby to zarządzanie datami często jest po prostu kłopotliwe w tym natywnym Date API, dzieje się…

Marek Piechut Nie wiem czy się z tobą zgodzę, że na początku te biblioteki były małe, bo takie biblioteki na początku to były jQuery’, małe biblioteki…

Bartek Witczak No dobra…, ale wiesz, chodzi o to…

Marek Piechut …znaczy tobie chodzi o leftpad, nie? Który wysypał cały świat, bo okazało się, że leftpad nie działa i wszystkie biblioteki świata przestały działać.

Bartek Witczak Mniej więcej o to mi chodzi…

Marek Piechut Przeszliśmy od tego, że w C trzeba było sobie pisać swoje kolekcje i swoje sortowanie i każdy to na studiach musiał przerabiać, do tego, że teraz nikt już pętli nie pisze, bo to jest za dużo pracy i trzeba by bibliotekę, żeby dodała cztery puste znaki po lewej czy po prawej, nie? To jest ciekawy kierunek..

Bartek Witczak Znaczy, wiesz, jeżeli, na przykład potrzebujemy w projekcie tylko i wyłącznie formatowania daty, to jaki jest problem, żeby po prostu sobie zrobić jakąś małą abstrakcję nad tym, jeżeli rzeczywiście masz ten jeden format i to będzie ultra lightweight super fast. Jakby nie będzie żadnego problemu z tym. Po co do takich rzeczy tworzone są biblioteki i potem, oczywiście, jest to rozgłaśniane jako niesamowity postęp ludzkości, że stworzyliśmy kolejną bibliotekę, która nic nie robi.

Marek Piechut Nie no, ja też widziałem, chyba, tą bibliotekę i ona jest też o tyle śmieszna, że ona ma tam niewiele możliwości formatowania tej daty – to nie jest tak, że formatujesz sobie co chcesz, tylko masz 5 jakieś predefiniowanych możliwych kombinacji i teraz, jasne, że można zrobić super light bibliotek, która będzie dopisywać stringa, którego do niej przekażesz, nie? To jest żaden sukces, zrobienie light’u i czegoś co niewiele robi, nie?

Bartek Witczak Yhy…

Marek Piechut Tym bardziej, jeszcze ta kwestia, że tak jak jest teraz w tych wszystkich webpack”ach i innych parcelach i innych nie wiadomo jakich bundler’ach, jest wszędzie tree shaking. To też nie wiem, czy jest to jakaś super z tego, że to będzie lightweight, nie? Pewnie jak byś wziął DataFNS to ta wielkość lightweight’u może by aż tak nie spadła w Twoim projekcie, a… pewnie będziesz potrzebował za chwilę tego, potem tego, potem parsowania, dodawania dni, usuwania dni i tak dalej,… znaczy odejmowania dni, przepraszam Cię. To wcale nie są trywialne rzeczy, nie? Myślę, że to się tylko tak wydaje, że „Oj nie, tam odejmę sobie dzień i będzie fajnie”, tylko, że każdy, kto z datami kiedykolwiek pracował, wie, że tak nie jest. Bo jest rok przestępny, są lata w których były jakieś dni w różnych time zone’ach i takie rzeczy. To nigdy nie jest takie proste…

Bartek Witczak No dobra, to powiedz mi, jakie by było twoje podejście, jeżeli chodzi o dokładanie w ogóle biblioteki - no zostańmy tutaj przy tych datach - do jakiegoś projektu. Bo ja, jeżeli zaczynam czy kontynuuje, rozwijam jakiś projekt, to przeważnie zaczynam od tego, że akurat teraz najczęściej korzystam z DateFNS i po prostu od tego sobie zaczynam, nie zastanawiam się do końca, jakich tam będę potrzebował operacji w danym projekcie, tylko po prostu w jakimś sensie by default, biorę bibliotekę DateFNS i z niej sobie korzystam.

Marek Piechut Znaczy, data, to jest w ogóle takim specyficznym problemem - mnie się wydaje - bo obsługa daty jest czymś jak obsługa UTFa i tak dalej, czyli na pierwszy rzut oka wydaje się, że nic nie potrzebujesz, bo to są proste rzeczy, a im dalej w las, to się okazuje, że coraz więcej, coraz więcej i jest tysiąc edge case’ów, których nie brałeś pod uwagę. Dlatego daty są o tyle kłopotliwe, że wydaje mi się, że zawsze jest warto wziąć jakąś bibliotekę, chyba, że masz bardzo trywialny przypadek - bo są bardzo duże szanse, że za chwilę tamten Twój kod, gdzieś tam napisany na kolanie, nie będzie spełniał, nie będzie zgodny z rzeczywistością, ze światem fizycznym, nie?

Bartek Witczak Yhy…

Marek Piechut Ale przy jakiś takich drobnych rzeczach, to nie wiem…, no dla mnie, jeżeli jestem w stanie napisać funkcje w trzy minuty albo w pięć, to nie chce mi się wchodzić nawet na NPM-a i szukać bibliotek. To jest takie wysuszanie tego kodowania do minimum, dochodzi do tego, że wrzucamy 57 bibliotek, potem próbujemy je wszystkie łączyć ze sobą i udajemy, że to działa. No ale, akurat daty, to jest zupełnie inny temat.

Bartek Witczak To jest ciekawe… Bo wydaje mi się, że początkowo, jak była taka duża popularność, MomentJS-a, to wystąpił taki problem, że w projektach, w różnych miejscach w kodzie, daty reprezentowane albo przez ten date object albo były prezentowane przez Momenta i czasami były jakieś lekkie problemy z tym związane, że dostawaliśmy datę w innym formacie niż nam się wydawało, tak że to nie był jakby date. Teraz już widzę, że bardziej korzystamy z natywnego DATE , a po prostu biblioteki, które mają jakieś tam utils’y, żeby działać na tych datach, korzystają z tego natywnego obiektu, nie?

Marek Piechut No tak, teraz wszystko idzie w tą stronę, żeby te obiekty dat były niemutowalne. Też trochę odchodzi się od tych bibliotek, które dokładają rzeczy do prototypów, żeby było fajnie i takie programowanie kropka, kropka, kropka, kropka…, że idziemy raczej w funkcje i składanie funkcji, a żeby funkcje były idempotentne, nie zmieniały świata zewnętrznego i ten Moment się tam nie sprawdza. Swoją drogą, przy okazji, z ostatnich newsów goście od Momenta - nie wiem, czy wiesz - powiedzieli, że moment jest skończony

Bartek Witczak No słyszałem coś.

Marek Piechut Moment no more, już nie będzie nowego kodu w Momencie. Moment jest w stanie jakim jest i w takim zostanie. Może to i dobrze, miała biblioteka swój czas.

Bartek Witczak No zdecydowanie.

Marek Piechut I teraz świat chyba poszedł trochę w innym kierunku. Poza tym zrobiła się trochę ogromniasta, po tej lightweightowości, ten poziom lightweightowości już przez sufit wyskoczył, bo nagle się okazuje, że Moment zajmuje tyle co reszta Twojego Softu.

Bartek Witczak Jeszcze z lokalizacjami…

Marek Piechut No lokalizacje, nie ma bundlera co by tam posprzątał, nie…

Bartek Witczak No dobra, teraz wydaje mi się, że jakby duży problem, jeżeli chodzi o korzystanie z bibliotek w projektach, to jest wyciekanie tej abstrakcji tych bibliotek do całego kodu. To, o czym często mówimy, to jest, że praktycznie bez względu na to, z jakiej będziemy korzystali biblioteki do formatowania, pasowania, zarządzenia tymi datami, to fajnie by było, żebyśmy po prostu w projekcie zrobili nasz jakiś wraper, na to zarządzanie datami, i wszystkie operacje przerzucali przez ten nasz kod. Wtedy jakby, po pierwsze uniezależnili się od tego problemu z jakiej biblioteki korzystamy, bo wszystko będzie u nas, po naszej stronie, a poza tym, to, wydaje mi się, da nam taką możliwość, że jeżeli my zobaczymy później, że zależy nam na tym, żeby tą aplikację odchudzić i okaże się, że w tym projekcie, to rzeczywiście korzystamy tylko z formatowania i parsowania dat, to wtedy możemy wymienić to sobie na coś lżejszego, ewentualnie napisać jakąś własną implementację, żeby już w ogóle było malutkie, nie?

Marek Piechut No, to jest dobra praktyka, taka, że odcinasz się od wewnętrznego kodu najbardziej jak się da. Tym bardziej, że pewnie jak operujesz datami, no to w jakiś tam dwóch przypadkach najbardziej, chociaż nie wiem, może to jest naciągane… No ale taki modelowy przypadek, to pierwsze to jest jakieś parsowanie danych, pewnie z back-endu czy z jakiegoś API, gdzie na pewno chcesz się odciąć od biblioteki i od tych rzeczy, bo tam na pewno musisz się odcinać od tego API, bo i tak będziesz mieć jakąś warstwę, która Cię oddziela. No i druga storna to jest frontend UI , gdzie musisz to wyrenderować. I tam, gdzie renderujesz, też pewnie masz jakieś predefiniowane formaty, które klient sobie życzy, albo konfigurowalne, albo zależne od języka czy od czegoś, gdzie pewnie też będziesz chciał, to mieć zebrane w jednym miejscu, żeby mieć spójność w UI. Chociaż, trochę to jest naciągane, bo na przykład jak czasami, jak już bardziej używasz tych dat, to używasz jakiś tam operacji bardziej na tych datach też, tak. Gdzie modyfikujesz, dodajesz dni, usuwasz dni, dodajesz tam tygodnie, miesiące. Nie wiem czy to jest takie proste, żeby w każdym miejscu się odcinać, żeby nie skończyć z czymś takim, że masz praktycznie opakowanie na całą bibliotekę i tak naprawdę masz praktycznie, to samo, co jest w tej bibliotece, tylko masz raper swój na to i delegujesz wszystko i nic więcej. Więc to też jest taka przesada duża. Tym bardziej, że teraz w jakimś TypeScipcie piszesz czy w czymś, to łatwiej jest znaleźć te wszystkie użycia i tak dalej, także nie był bym może aż tak faszystą, że wszystko trzeba gdzieś tam zapakować..

Bartek Witczak Nie, ja bym mimo wszystko wolał się gdzieś tam nie odcinać od tego. Nawet ostatnio mieliśmy taką sytuację w projekcie, gdzie DateFNS był aktualizowany z V1 do V2, tam dosyć sporo się zmieniało…, i w naszym produkcie to było i były jakieś tam pojedyncze fuckup’y z tym, że część rzeczy nie została zmieniona.

Marek Piechut Bo tam dużo było właśnie fuckup-ów. To jest w ogóle ciekawy, inny problem, że ktoś poszalał, w sensie twórca DateFNS’a poszalał, bo jasne, że każdy z nas się uczy, ale po prostu zmienianie parametrów do formatowania dat, które są stringami na inne formaty, bo te są fajniejsze, nowsze, lepsze albo coś takiego, to jest jakaś taka forma sadyzmu na Twoich użytkownikach i nie wiem… Ja, po prostu, wspominam jakieś czasy, gdzie w Javie było Apache Commons, które jak wyszło w ‘97 to podbijali wersje do 2017 czy ‘20 i się nic nigdy nie działo, wszystko działało tak jak trzeba. A teraz dochodzimy do tego, że ty musisz swój kod przeglądać, bo ktoś powie „Nie, nie, nie może się funkcja nazywać do it musi się nazywać make it”. I kit, ty musisz szukać i zmieniać wszystko. To też jest jakieś takie szaleństwo.

Bartek Witczak No wiesz, właśnie dlatego, według mnie, ten element takiej dojrzałości języka i dojrzałości tego community, to też jest jakby czynnik, który, wydaje mi się, dobrze mieć na uwadze i takimi wraperami móc się odciąć od tego wszystkiego.

Marek Piechut No tak, to jest zdecydowanie dobra taktyka.

Bartek Witczak No dobra, mamy to…

Marek Piechut No to teraz przejdźmy do mojego tematu. A mój temat jest, znowu, tak trochę wyliczeniowy, ale już tam się wyleżakował przez miesiąc ponad, więc trzeba go w końcu ruszyć. A ten temat to jest Apollo Client w wersji 3.0, także, jeżeli ktoś żyje w świecie GraphQL-a i Reacta, to pewnie coś tam o Apollo słyszał, no i wersja 3.0 wprowadza trochę ciekawych zmian. Ja na nią czekałem szczególnie dlatego, że już od dłuższego czasu jechaliśmy na wersji 3.0 Beta, bodajże jakieś Beta 20 i ona była na produkcje od jakiegoś czasu. To było spowodowane taką rzeczą - dobrze że mamy technicznych słuchaczy, to mogę takie rzeczy opowiadać – to było spowodowane tym, że mieliśmy polimorficzne typy w naszym GraphQL-u i to rozwiązywanie polimorfizmu na kliencie było niemożliwe w starym GraphQL, przed wersją 3.0, a w 3.0 już można te typy, gdzieś tam wyciągać, polimorficznie.

No dobra, tylko wytłumacz, czym są te typy polimorficzne.

Marek Piechut No po prostu możesz mieć, ni mniej ni więcej, tylko dziedziczenie typów, tak.

No dobra…

Marek Piechut Co, jakby wcześniej, musiałeś zawsze mieć w GraphQL-u taki typ agreguacyj te wszystkie atrybuty i jego przesyłać, i tam już na kliencie sobie zgadywać, że może to to, a może to tamto. A w Apollo od wersji 3 możesz po prostu zrobić w konfiguracji tego klienta, że jeżeli przychodzi taki type name to zrób taki typ, a taki type name to zrób taki typ, wszystko sobie śmiga. Także to jest taki aspekt tego, co mnie osobiście dotyka, bo to jest w naszym projekcie. No ale doszło też trochę innych ciekawych rzeczy. Na przykład, z takich, wydawało by się, trywialnych, ale męczących kiedyś…, czyli wreszcie jest jedna paczka, która się nazywała Apollo Client, a nie już tam: Apollo Client Error Handler 1, Apollo Client coś tam i to wszystko instalujesz, po prostu…

Bartek Witczak No to jest ten etap dojrzewania bibliotek…

Marek Piechut Kiedyś też tak było, na początku, że była jakaś biblioteka, potem była rozbita na kilka i potem wróciła z powrotem do jednej, ale mnie się ta wersja z jedną dużo bardziej podoba. Z innych ciekawych rzeczy jest to, że wreszcie cache ma garbage collection, czyli nie jest niekończącą się, puchnącą kulą, wszystkiego co tam do niej wepchniesz, tylko wreszcie można rzeczy z niego wyrzucać i on sobie tam sprząta. Można wywołać garbage collector, on tam wyrzuca rzeczy, które już są nie potrzebne, bo nic tam do nich nie trzyma referencji, tak?

Bartek Witczak Yhy…

Marek Piechut Czyli, jak tam żaden qiery nie używa obiektów albo inne root obiekty nie używają obiektów, to można wyczyścić i idzie. Także takie rzeczy się stały. Są jakieś nowe reactive variables, mnie jakoś to nie kręci bardzo, ale jak ktoś trzyma swój stan lokalny, stan klienta bardziej w GraphQL-u no to, to pewnie go to rusza. Tam trzymanie tego stanu – nie wiem jakie są Twoje odczucia – moje jest takie, że z tym jest średnio, z tym utrzymywaniem.

Bartek Witczak Z tym był spory problem, chyba nawet mieliśmy swoja strategię, gdzie ten GraphQL-owy był napisany, żeby za każdym razem robić tego network fetch po dane ….

Marek Piechut Znaczy…, bardziej mi chodzi, wiesz o trzymanie stanu lokalnego aplikacji, czyli wyrzucasz Reduxa i trzymasz sobie wszystko w GraphQL-u.

Bartek Witczak No dokładnie, dokładnie.

Marek Piechut My ostatecznie skończyliśmy z trzymaniem wszystkiego w GraphQLu, ale większość rzeczy pchamy przez back-end zawsze. No ale jak masz więcej tych operacji takich typowo frontendowych, których nie chcesz pchać przez back-end, no to tam musiałeś pisać te lokalne mutacje i tak dalej, i to było średnio wygodne.

Bartek Witczak O to mi chodzi, że my się tego pozbyliśmy, bo tam jakby… Jest nawet trochę prezentacji w necie o firmach, jak rozwiązują takie problemy z tymi mutacjami, przy jakiś właśnie update’ach danych i my bardziej poszliśmy w tą stronę, że za każdym razem, po prostu pobieramy świeże dane i ten nasz lokalny cache był taki minimalny.

Marek Piechut No tak, zresztą tak chcieliśmy mieć, żeby jak najwięcej rzeczy szło przez back-end i było aktualnych, nie?

Bartek Witczak Dokładnie

Marek Piechut No, ale jak tam nie chcesz mieć rzeczy wszystkich na back-endzie, no bo tam operacje dzielą się typowo front-endowo, albo jest bardzo dużo tego, no to używanie tych lokalnych mutacji było męczące bardzo, nie?

Bartek Witczak …Strasznie

Marek Piechut A tu masz reactive variables, to można to dużo łatwiej załatwić, że tamte rzeczy trzymasz sobie tylko w tych variablach i one same odświeżają. Generalnie chodzi o to, że jeżeli masz jakieś zapięte na te reactive variables, czyli można je, gdzieś tam wkładać w środek tego Graph-u, to one się będą automatycznie odświeżać, jak tylko będzie się lokalnie zmieniał, więc to jest…, można powiedzieć, na lokalny stan tego używać. No i to myślę, że dużo upraszcza. Weszło też coś takiego jak filtr policy. To generalnie wygląda dosyć fajnie, jak masz jakieś dane wywodzone, na przykład ze swojego Graph’a, czyli nie ściągasz samego Graph’u i go bezpośredni pchasz do komponentów, tylko, gdzieś tam, potrzebujesz mieć jakieś dane wyuczone albo coś takiego, albo masz właśnie dane, które są typowo trzymane na kliencie i przy użyciu tego, można sobie te rzeczy przetwarzać. Deklaruje, że wszystkie tam ready czy odczyty, czy zapisy do jakiegoś tam kawałka drzewa przechodzą przez te twoje funkcje i są gdzieś tam przetwarzane. To jest też spoko.

Bartek Witczak Super jest, no.

Marek Piechut To jest też spoko. I ostatnia, taka większa, ciekawa sprawa to są helpery do paginacji. Nie wiem, czy ty kojarzysz nasz kod do stronicowania, w GraphQL jest trochę zabawy, żeby to zrobić. Tam jest…, niby support do stronicowania był, ale zawsze to się wiązało z tym, że trzeba było dużo tego kodu naukowo napisać.

Bartek Witczak Zgadza się, zgadza się – to pamiętam. Bo tam bardzo tych …… (5:58) na około muszą powstać.

Marek Piechut No bo musisz fetchować ten pierwszy, potem masz fetchowanie innych stron, wszystko to są jakieś dodatkowe QRysy, które dodatkowo musisz gdzieś tam opisać w Graph-ie i sobie te rzeczy dofetchowywać. No i teraz, to co doszło, to jest to, że oni dwa common case’y z fatchowaniem ze stronicowaniem rozwiązali, czyli fetchowanie po offset-cie, to jest jedno, no i fetchowanie po jakimś kursorze, nie? Także, nie wiem, ludzie pewnie jakieś inne rozwiązania czasem wprowadzają, ale to,mi się wydaje, jest takie na maksa popularne… Dwa podejścia, które są używane i takie helpery dodali, które łatwo jest użyć. Praktycznie nie musisz się bawić już sam z tym samodzielnym stronicowaniem. Dużo łatwiej jest tego użyć. Co ciekawe, można to spiąć jeszcze z tym wcześniejszym, o czym mówiłem, z tym filtr points i wtedy już w ogóle, to jest w miarę przezroczyste, że po prostu te rzeczy będą się ładować, jak będziesz dojeżdżał do końca.

Bartek Witczak To brzmi bardzo fajnie.

Marek Piechut Także, to jest spoko. No i generalnie jest, według mnie, bardzo fajnie. Jestem dosyć zadowolony z naszego przejścia z Reduxa i restowych jakiś tam wywołań na GraphQL-a, nie wiem jak Twoje odczucia?

Bartek Witczak No, u mnie jest podobnie. My, jakby, zaczęliśmy od tego standardowego stacku z Reduxem z restami i powoli przechodziliśmy do tego GraphQL-a. Koniec końców już na webie został nam tylko GraphQL.

Marek Piechut No tam na mobilce chyba też, w sumie…poza jakimiś drobnymi…

Bartek Witczak Na mobilce ostatnie szły już przez GraphQL-a, ale część rzeczy i tak szła przez Resta, ale co ciekawe, pewnie też sobie kiedyś o tym pogadamy, ale na mobilce, pomimo tego, że wykorzystaliśmy React Native, to my nie mieliśmy Reduxa. Tam mamy lokalną bazę SQLite, to tak jakby nie było w ogóle Reduxa, więc tam mieliśmy początkowo po prostu restcole, a potem już te nowsze rzeczy wprowadzaliśmy już GraphQL-em.

Marek Piechut Tak, to też chodziło nam o to, żeby zmniejszyć utrzymywanie tych różnych interfejsów, które są nie potrzebne.

Bartek Witczak Dokładnie.

Marek Piechut A prawda jest taka, że jak wyrzucisz cash z GraphQL-a, no to można na spokojnie dojść do takiego prostego APC i nie ma z tym żadnych problemów. Biblioteki są malutkie, wszystko sobie fajnie działa i o ile nie chcesz na to bardzo słuchać czegoś, tylko po prostu wykonywać jakieś cole w stylu Resta, to się też świetnie sprawdza.

Bartek Witczak Znaczy…, no, według mnie GraphQL naprawdę fajną robi robotę. Powiedzmy, te obietnice, które składa to realizuje bardzo fajnie, także…

Marek Piechut Jest tam trochę psikusów… Nie łatwo się wywalić na n+1 zapytań i tym podobnych rzeczach…

Bartek Witczak Dokładnie.

Marek Piechut Skrajnie nieoptymalne rozwiązanie i trzeba nad nim trochę tam posiedzieć, po prostu. Tam jest bardzo łatwo robić zapytania, które będą bardzo kosztowne

Bartek Witczak Yhy…

Marek Piechut Gdzie przy pisaniu RESTem, albo miał byś dużo requestów i wtedy byś się stukną w głowę „Oooo, trochę za długo to trwa”, albo byś miał… ,za każdym razem musiał pisać nowy end-point, „Oooo, że end-point, tu są queries one coś tam robią” i tak dalej. To jest duży end-point, to jest mniejszy, tu jest mniejszy, to jest dla takiej kombinacji, tt jest dla takiej, nie…

Bartek Witczak Znaczy, to też całkiem fajnie przechodziła ta transformacja, bo jak przechodziliśmy tego GraphQL-a to zaczęło się od takiej rzeczywiście pojedynczych strzałów do jakiś zasobów, a potem rzeczywiście zaczęliśmy już bardziej budować to w formie tego drzewa i tak koniec końcu, to jakby już kończyło się tak, powiedzmy, tak trywialnie. I to, jak już wtedy było tak ładnie, i powiedzmy jakiegoś tam jednego roota rozszerzamy dalej, to rzeczywiście wtedy można było sobie wyciągać te dane, które potrzebujesz do danych komponentów, do danych stron.

Marek Piechut Nie, bo tutaj właśnie przechodziliśmy, że było widać, że taka była ewolucja od tego, że właściwie mamy RESTa, tylko go zrobiliśmy w GraphQL-u, czyli mamy dużo różnych end-pointów, które możesz zapytać, dużo queries, które możesz zapytać. Przeszliśmy w końcu do tego, że masz kilka tylko takich rootów, z których możesz budować taki duży, dowolny graf.

Bartek Witczak Dokładnie

Marek Piechut I to jest taki, mi się wydaje, naturalny kierunek, że zaczynasz od tego, że masz dużo różnych queries, a kończysz na dużym, jednym grafie. Może jeden, to trochę przesada, ale że kończysz na kilku takich root obiektach, które możesz ściągać i gdzieś tam, po kawałku, po kawałku sobie budujesz takie drzewko i też Ci się wyciągają, nie…

Bartek Witczak Powiem Ci, że to, co mnie się najbardziej podobało w tym GraphQL-u, to jest to, że biorąc pod uwagę, że mieliśmy aplikacje otypowane, akurat we FLOW, to podoba mi się ten element, że tak naprawdę przy stworzeniu tych takich głównych typów, potem wszędzie, jak korzystasz z tego GraphQL-a, to praktycznie wyciągasz sobie te odpowiednie propertiesy z danych typów interfejsów. I to jest takie mega spójne, że praktycznie masz raz deklarowaną jakąś taką grupę typów - dużą, a potem wszystkie te typy pochodne, budujesz już sobie z tych typów bazowych. Kontrastując to do takiego RESTa, gdzie każda reprezentacja tych obiektów może być na każdym end-point przesłana trochę inaczej. Jakimiś, nie wiem, innymi nazwami pól, z jakimiś innymi trochę typami, takimi rzeczami, nie… Tu jednak było już mega spójnie potem.

Marek Piechut Znaczy, to też jest w tym…, że jeżeli te typy tak deklarujesz, w miarę mapujesz je na takie biznesowe obiekty, to okazuje się, to okazuje się, że obiekty… Dobra polećmy jakoś, w stylu, że obiekty masz jeden typu faktura masz jeden typ i on ma różne pola, tak. I jeżeli pisał byś RESTa, to prawdopodobnie miał byś miejsce, gdzie zwracasz tam trzy pola, w drugim REST zwracasz pięć, bo Ci było akurat potrzeba. No i potem, jak ktoś pisze tego klienta, to mu tu brakuje, tam ma za dużo, tu coś tam. I zawsze są takie problemy, a tu się okazuje, że jak napisałeś to raz, to już teraz po stronie klienta jest całkowicie decyzja, czy on chce te rzeczy dostać czy on nie chce dostać. Może sobie tam zawsze dociągnąć i to bardzo fanie działa. Poza jednym aspektem, że czasami trzeba przyjrzeć się co nam zeżarło cały RAM, albo…całego proca…

Bartek Witczak No, to jest jedno - serwer, a drugi to jest to, o czym mówiliśmy nawet przy naszym przechodzeniu, żeby nie traktować tego, tak dosłownie jako przejście z RESTa, tylko, jednak na tą strukturę, trzeba trochę inaczej popatrzeć.

Marek Piechut Tak, trzeba trochę patrzeć na to inaczej, trzeba trochę przemyśleć też, czy te wszystkie swoje struktury i to podejście w ogóle do zapytań na back-end…

Bartek Witczak Ale ja bardzo polecam.

Marek Piechut I Apollo Cient, to też jest taka druga rzecz, która, myśleliśmy, że tam jest dużo magii, która będzie nas gryzła w tyłek, a ostatecznie okazało się, że nie było tam jakiś strasznie dużo problemów z tym cache,, że ostatecznie działało to całkiem nieźle i przewidywalnie.

Bartek Witczak Dokładnie. No szczególnie, jak my sobie ułatwiliśmy tą drogę i postanowiliśmy, że praktycznie zawsze będziemy się pytali back-endu o dane najnowsze..

Marek Piechut No, może nie aż tak zawsze. No, ale…

Bartek Witczak Prawie zawsze.

Marek Piechut ….prawie zawsze.

Bartek Witczak No dobra, to co, dajemy łapkę w górę i ściągamy.

Marek Piechut Łapka w górę

Bartek Witczak Łapka w górę, Apollo ściągamy i porzucamy RESTa w aplikacjach, w których nie musi go być, szczególnie, kiedy samemu się jest panem back-endu i front-endu, i nie trzeba API takiego oficjalnego mieć to mi się wydaje, że jest fajne.

Marek Piechut Super