Smashing Podcast Episode 31 z Eve Porcello: Co to jest GraphQL?

W tym odcinku mówimy o GraphQL. Co to jest i jak rozwiązuje niektóre typowe problemy z interfejsem API? Aby się tego dowiedzieć, rozmawiałem z ekspertką Eve Porcello.

Pokaż notatki

• Ewa na Twitterze
• Firma Ewy Moon Highway
• Nauka GraphQL od O'Reilly
• Discover Your Path Through The GraphQL Wilderness — warsztaty Eve's GraphQL rozpoczynają się na początku 2021 r.

Cotygodniowa aktualizacja

• Jak korzystać z MDX przechowywanego w zdrowiu w witrynie Next.js?
  napisany przez Jasona Lengstorfa
• Tworzenie konwersacyjnego chatbota obsługującego NLP przy użyciu Google Dialogflow
  napisany przez Nwani Victory
• Rozważania etyczne w badaniach UX: potrzeba szkolenia i przeglądu
  napisany przez Victora Yocco
• Łatwiejsze rozmowy na stronach internetowych
  napisany przez Fredericka O'Brien
• Jak zaprojektować prosty interfejs użytkownika, gdy masz złożone rozwiązanie
  napisane przez Suzanne Scacca

Transkrypcja

Drew McLellan: Jest inżynierem oprogramowania, instruktorem, autorem i współzałożycielem firmy Moon Highway zajmującej się szkoleniami i opracowywaniem programów nauczania. Jej kariera rozpoczęła się od pisania specyfikacji technicznych i tworzenia projektów UX dla projektów internetowych. Odkąd założyła Moon Highway w 2012 roku, tworzyła materiały wideo dla egghead.io i LinkedIn Learning, a także jest współautorką książek Learning React i Learning GraphQL dla O'Reilly's Media.

Drew: Jest również częstym prelegentem konferencyjnym i występowała na konferencjach, w tym React Rally, GraphQL Summit i OSCON. Więc wiemy, że jest ekspertem w GraphQL, ale czy wiesz, że kiedyś nauczyła niedźwiedzia polarnego grać w szachy? Moi drodzy przyjaciele, witajcie Eve Porcello.

Drew: Cześć Eve, jak się masz?

Eve Porcello: Rozwalam.

Drew: Jak już wspomniałem, jesteś nauczycielem takich rzeczy jak JavaScript i React, ale chciałem z tobą dzisiaj porozmawiać o jednym z twoich innych specjalistycznych obszarów, GraphQL. Wielu z nas słyszało w pewnym stopniu o GraphQL, ale może nie być do końca pewni, co to jest lub co robi, aw szczególności, jaki rodzaj problemu rozwiązuje w stosie sieciowym.

Drew: Więc przygotuj dla nas scenę, jeśli chcesz, jeśli jestem front-end developerem, gdzie GraphQL wpasowuje się w ekosystem i jaką funkcję pełni dla mnie?

Ewa: Tak. GraphQL wpasowuje się pomiędzy front end a backend. Jest to rodzaj życia pomiędzy tymi dwoma i daje wiele korzyści programistom front-end i back-end developerom.

Eve: Jeśli jesteś programistą front-end, możesz zdefiniować wszystkie wymagania dotyczące danych front-end. Więc jeśli masz na przykład dużą listę komponentów React, możesz napisać zapytanie. I to zdefiniuje wszystkie pola, które trzeba by wypełnić danymi dla tej strony.

Eve: Teraz, jeśli chodzi o backend, jest naprawdę własny, ponieważ możemy zebrać wiele danych z wielu różnych źródeł. Mamy więc dane w REST API, w bazach danych i we wszystkich tych różnych miejscach. A GraphQL zapewnia nam tę przyjemną, małą warstwę orkiestracji, aby naprawdę zrozumieć chaos związany z miejscem, w którym znajdują się wszystkie nasze dane. Więc jest to naprawdę przydatne dla każdego rodzaju stosu.

Drew: Więc jest to zasadniczo technologia oparta na API, prawda? Znajduje się między twoim frontendem a backendem i zapewnia jakiś rodzaj API, czy to prawda?

Eve: Tak, dokładnie tak. Dokładnie tak.

Drew: Myślę, że przez ostatnią dekadę złotym standardem dla API była reszta. Jeśli więc masz aplikację po stronie klienta i musisz wypełnić ją danymi z zaplecza, zbudujesz punkt końcowy interfejsu API REST i wykonasz zapytanie. Więc gdzie upada ten model? A kiedy możemy potrzebować GraphQL, aby się pojawił i rozwiązał to za nas?

Eve: Cóż, problem, w rozwiązaniu którego GraphQL naprawdę nam pomaga, rodzaj złotego problemu, złote rozwiązanie, jak sądzę, zapewniane przez GraphQL polega na tym, że z REST pobieramy zbyt dużo danych. Więc jeśli mam slashowych użytkowników lub slashowe produkty, zwrócę mi wszystkie dane za każdym razem, gdy trafię na trasę.

Eve: Dzięki GraphQL możemy być nieco bardziej wybredni w wyborze danych, których potrzebujemy. Więc jeśli potrzebuję tylko czterech pól z obiektu, który ma sto, będę w stanie naprawdę wskazać te pola i nie będę musiał ładować danych ani ładować wszystkich tych danych, co powinienem powiedzieć, do twojego urządzenia, ponieważ to dużo dodatkowej pracy, zwłaszcza dla twojego telefonu.

Drew: Widziałem i pracowałem z REST API w przeszłości, które mają opcjonalne pole, w którym możesz przekazać listę danych, które chcesz odzyskać, lub możesz rozszerzyć to, co wraca, o dodatkowe rzeczy. A więc myślę, że to identyfikuje ten problem, prawda? To znaczy, że nie zawsze chcesz odzyskać te same dane za każdym razem. Czy to dlatego, że GraphQL formalizuje to podejście pozwalające front-endowi na określenie, co backend ma zwrócić pod względem danych?

Eve: Tak, dokładnie. Twoje zapytanie staje się więc sposobem, w jaki pytasz, jak filtrujesz, jak chwytasz wszelkiego rodzaju informacje z dowolnego miejsca.

Eve: Myślę też, że ważne jest, aby pamiętać, że nie musimy niszczyć wszystkich naszych interfejsów API REST, aby naprawdę pomyślnie pracować z GraphQL. Wiele z najbardziej udanych implementacji GraphQL, jakie widziałem, to wrappery wokół interfejsów API REST. Zapytanie GraphQL naprawdę daje Ci sposób na zastanowienie się, jakich danych potrzebujesz. A może część danych pochodzi od naszych użytkowników i produktów, przykłady, część danych pochodzi z REST, część z bazy danych.

Drew: Wydaje mi się, że znany scenariusz jest taki, że możesz mieć punkt końcowy w swojej witrynie, który zwraca informacje o użytkowniku w celu wyświetlenia nagłówka. Może dać ci ich nazwę użytkownika i awatar. I wycinasz to na każdej stronie i wypełniasz dane, ale potem znajdujesz gdzieś indziej w swojej aplikacji, gdzie musisz wyświetlić ich pełną nazwę.

Drew: Więc dodajesz to do punktu końcowego i zaczyna to zwracać. A potem robisz sekcję zarządzania kontem i potrzebujesz jak ich adres pocztowy. Więc to również zostanie zwrócone przez ten punkt końcowy.

Drew: I zanim się zorientujesz, ten punkt końcowy zwraca cały ciężki ładunek, który kosztuje sporo na zapleczu, aby go złożyć, i oczywiście dużo do pobrania.

Drew: I to było wybierane na każdej stronie tylko po to, by pokazać awatar. Sądzę więc, że jest to rodzaj problemu, który narasta z czasem, na który tak łatwo było wpaść, szczególnie w dużych zespołach, że GraphQL jest na szczycie tego problemu. Wie, jak to rozwiązać i ma na celu rozwiązanie tego.

Ewa: Dokładnie. I tak, myślę, że cała idea schematu GraphQL, myślę, że jest tak naprawdę mniej omawiana niż część GraphQL dotycząca języka zapytań. Ale naprawdę czuję, że w szczególności schemat daje nam ten fajny system typów dla API.

Eve: Więc każdy w zespole, menedżerowie, programiści front-end, programiści back-end, każdy, kto naprawdę zajmuje się danymi, może się zebrać, zjednoczyć się wokół danych, które faktycznie chcemy udostępniać w tym interfejsie API, a wtedy wszyscy wiedzą, jakie to źródło Prawda jest taka, że ​​mogą na tej podstawie budować własne części aplikacji.

Eve: Więc jest też kilka trudnych rzeczy związanych z zarządzaniem schematami, które się z tym wiążą. Ale jeśli chodzi o przejście z mikrousług z powrotem do monolitów, robimy to, ale nadal uzyskujemy wszystkie korzyści, które lubimy, z mikrousług.

Drew: I czy dobrze rozumiem, że typowym sposobem konfigurowania systemu GraphQL jest to, że masz w zasadzie jedną trasę, która jest punktem końcowym, do którego wysyłasz wszystkie swoje zapytania, więc nie musisz… Często jeden z Najtrudniejszą rzeczą jest ustalenie, jak nazwać i jaka powinna być ścieżka, na której powinno być to konkretne zapytanie. To powracający użytkownicy i produkty, czy powinno to być slashowanie czegoś dla użytkowników, czy cięcie czegoś?

Drew: Dzięki GraphQL masz tylko jeden punkt końcowy, do którego po prostu uruchamiasz swoje zapytania i otrzymujesz odpowiednią odpowiedź.

Ewa: Dokładnie. Tak. To pojedynczy punkt końcowy. Myślę, że nadal masz problemy z nazywaniem, ponieważ nazywasz wszystko w Schema. Ale jeśli chodzi o to, że czuję się jak wiele firm, które poczyniły duże zakłady na mikrousługi, wszyscy są jak, jakie mamy punkty końcowe? Gdzie oni są? Jak są udokumentowane? A dzięki GraphQL mamy jedno miejsce, jeden rodzaj słownika do wyszukiwania wszystkiego, czego chcemy się dowiedzieć o działaniu API.

Drew: Tak więc, jestem bardzo zaznajomiony z innymi językami zapytań, na przykład SQL jest oczywistym przykładem języka zapytań, który zna wielu programistów internetowych. A zapytania w tym przybierają formę prawie jak polecenie. To ciąg tekstowy, prawda? Wybierz to z tamtego, gdzie, cokolwiek. Jaki format przyjmują zapytania w GraphQL?

Eve: To wciąż ciąg technologiczny, ale nie definiuje, skąd bierze się ta logika. I duża część logiki zostaje przeniesiona z powrotem na serwer. Tak więc serwer GraphQL, API GraphQL jest naprawdę odpowiedzialny za powiedzenie: „Idź weź te dane tam, gdzie są, filtruj je na podstawie tych parametrów”.

Eve: Ale w języku zapytań jest bardzo zorientowany na pola. Więc po prostu dodajemy pola dla wszystkiego, co chcemy pobrać. Oczywiście w przypadku tych zapytań możemy również umieścić filtry. Ale myślę, że jest trochę mniej bezpośrednie, skąd pochodzą te informacje. Wiele funkcji jest wbudowanych w serwer.

Drew: Możesz więc mieszać i dopasowywać w zapytaniu. Możesz złożyć żądanie, które w jednym żądaniu zwraca wiele różnych typów danych. Czy to prawda?

Eve: Tak, zgadza się. Możesz więc wysłać zapytanie dla tylu pól, na ile pozwoli twój serwer, i przywrócić wszystkie rodzaje zagnieżdżonych danych. Ale tak to naprawdę działa, łączymy różne typy na polach. Sądzę więc, że odtworzymy mój pomysł na użytkowników i produkty, ale użytkownik może mieć pole produktów, które zwraca listę produktów. Wszystkie one są również powiązane z innymi typami. Więc tak głęboko zagnieżdżone, jak chcemy, aby zapytanie poszło, możemy.

Drew: Czy to oznacza pobranie danych dla typowego widoku w aplikacji internetowej, w którym mogą się dziać różne rzeczy, że wystarczy wysłać jedno żądanie do zaplecza i uzyskać to wszystko za jednym razem, bez konieczności wprowadzania innych zapytania do różnych punktów końcowych, bo to tylko jedna rzecz?

Ewa: Tak. To jest dokładnie cały cel, to tylko jedno zapytanie, zdefiniuj każde pole, które chcesz, a następnie zwróć je w jednej odpowiedzi.

Drew: A zapytania są oparte na JSON, czy to prawda?

Eve: samo zapytanie jest ciągiem tekstowym, ale zazwyczaj zwraca dane JSON. Jeśli więc mam pola, moja odpowiedź JSON jest dokładnie dopasowana, więc jest naprawdę jasne, co otrzymujesz, gdy wysyłasz to zapytanie, ponieważ odpowiedź dotycząca danych wygląda dokładnie tak samo.

Drew: Wydaje się, że wiele zapytań dotyczy prawie nagich obiektów, takich jak klient lub produkt. Czy istnieje sposób na określenie bardziej złożonych zapytań, w których logika biznesowa jest kontrolowana na zapleczu? Powiedzmy, że chcę uzyskać listę zespołów dla użytkownika, ale tylko w przypadku, gdy ten użytkownik jest administratorem zespołu i gdy plan zespołu nie wygasł, oraz wszystkie tego rodzaju rzeczywiste ograniczenia, z którymi mamy do czynienia w codziennym tworzeniu aplikacji internetowych. Czy można to osiągnąć dzięki GraphQL?

Ewa: Absolutnie. Więc to jest naprawdę ekscytujące i potężne w GraphQL jest to, że możesz przenieść wiele tej logiki na serwer. Jeśli masz złożone zapytanie, jakiś naprawdę konkretny typ użytkownika, którego chcesz uzyskać, wszystko, co musisz zrobić w Schema, to powiedzieć „Pobierz skomplikowanego użytkownika”, a następnie na serwerze byłaby funkcja, w której możesz napisać całą logikę w dowolnym języku. JavaScript jest w pewnym sensie najpopularniejszym językiem implementacji GraphQL, ale nie musisz go w ogóle używać. Więc Python, Go, C++, czegokolwiek chcesz użyć, możesz zbudować z tego serwer GraphQL. Ale tak, możesz zdefiniować tak złożone zapytanie, jak chcesz.

Drew: I wydaje mi się, że pozwala to zawrzeć dużo logiki biznesowej w nowych typach obiektów. Czy to w porządku? Wiesz, konfigurujesz skomplikowanego użytkownika, a potem nie musisz myśleć, kim jest skomplikowany użytkownik, ale możesz po prostu nadal używać tego skomplikowanego użytkownika i wiedzieć, że logika biznesowa jest na nim zaimplementowana. Czy to prawda?

Eve: Dokładnie tak. Myślę więc, że jest to naprawdę miłe dla ludzi zajmujących się frontendem, ponieważ mogą na tej podstawie zacząć prototypować. A wtedy zespół backendowy mógłby wdrożyć te funkcje, aby to zadziałało. A potem jest coś w rodzaju tego wspólnego zrozumienia, czym właściwie jest ten typ i kim oni są, oraz „Jakie są pola w tym typie?” I wszystko może być obsługiwane przez gdziekolwiek na stosie działa GraphQL. I właśnie dlatego tak naprawdę nie jest to technologia front-end ani back-end. To naprawdę jedno i drugie, i żadne.

Drew: Wygląda na to, że jest to rodzaj sformalizowania API i relacji między frontendem a backendem, więc każdy otrzymuje przewidywalny interfejs, który jest ustandaryzowany.

Ewa: Dokładnie.

Drew: Co, jak sądzę, w organizacjach, w których frontend i backend należą do różnych zespołów, co nie jest niczym niezwykłym, sądzę, że takie podejście umożliwia również wprowadzanie zmian, powiedzmy, we frontendzie, może to wymagać innych danych, bez potrzeby kogoś, kto pracuje na backendzie, aby wprowadzić zmiany, które im odpowiadają. Nadal masz ten interfejs API, który można prawie nieskończenie dostosowywać, bez konieczności wykonywania jakichkolwiek prac, aby go zmienić, jeśli potrzebujesz nowych danych.

Eve: Tak, dokładnie tak.

Drew: Czy serwer GraphQL jest odpowiedzialny za formatowanie odpowiedzi, czy też musisz to zrobić w logice po stronie serwera?

Eve: Więc serwer GraphQL definiuje dwie rzeczy. Definiuje sam schemat, który znajduje się na serwerze, a następnie definiuje funkcje przelicznika. Są to funkcje, które pobierają dane z dowolnego miejsca. Więc jeśli mam API REST, które pakuję za pomocą GraphQL, przelicznik pobierałby z tego API, przekształcał dane tak, jak było to potrzebne, a następnie zwracał je klientowi w tej funkcji. Na tym serwerze możesz również używać dowolnych funkcji bazy danych. Więc jeśli masz dane w wielu różnych miejscach, jest to naprawdę przyjemne, spójne miejsce, w którym można umieścić wszystkie te dane i zaprojektować całą logikę wokół: „Skąd pochodzą te dane? Jak chcemy to zmienić?”

Drew: Klient mówi: „Chcę użytkownika złożonego”, serwer otrzymuje to w zapytaniu i może powiedzieć: „Dobrze, zamierzam sprawdzić program rozpoznawania użytkowników złożonych”. Czy to prawda?

Ewa: Mm-hmm (tak).

Drew: Która to funkcja, a następnie piszesz swoją logikę, aby Twój zespół backendowy lub ktokolwiek inny pisze logikę wewnątrz tej funkcji, zrobił wszystko, co konieczne, aby zwrócić złożonemu użytkownikowi.

Eve: Tak, dokładnie.

Drew: Może to być wywoływanie innych API, może to być zapytanie do bazy danych, może to być wyszukiwanie rzeczy w pamięci podręcznej lub prawie cokolwiek.

Eve: Prawie wszystko. A potem, o ile ten zwrot z funkcji będzie odpowiadał wymaganiom Schema, jakie pola, jakie typy tam wracały, to wszystko będzie ładnie i harmonijnie działać.

Drew: Wydaje mi się, że domyślnie daje to spójny format odpowiedzi w całym interfejsie API. Nie musisz projektować, jak to wygląda. Po prostu otrzymujesz spójny wynik.

Eve: Tak, dokładnie.

Drew: Myślę, że to może być naprawdę wygrana, ponieważ utrzymanie spójności w szerokim zakresie punktów końcowych API może być naprawdę trudne, szczególnie w większych zespołach. Różni ludzie pracują nad różnymi rzeczami. Jeśli nie masz dość rygorystycznego zarządzania, może się to bardzo szybko skomplikować, prawda?

Eve: Tak, absolutnie. I myślę, że Schema to taki fajny mały dokument do opisu wszystkiego. Otrzymujesz automatyczną korzyść w postaci możliwości zobaczenia wszystkich pól w tym schemacie za każdym razem, gdy próbujesz wysłać do niego zapytania, ponieważ możesz wysyłać zapytania introspekcyjne i jest wiele fajnych narzędzi do tego, takich jak GraphQL i GraphQL Playground, małe narzędzia, których możesz użyć do interakcji z danymi API.

Eve: Ale także, jeśli kiedykolwiek bawiłeś się Postmanem, lubiłeś pingować API REST, wiele z nich, dokumentacja tak naprawdę nie istnieje lub jest trudna do znalezienia, lub takie rzeczy. GraphQL naprawdę daje ci tę przyjemną spójną warstwę do opisania wszystkiego, co może być częścią tego API.

Drew: Praktycznie, jak to działa po stronie serwera? To znaczy, myślę, że musisz uruchomić usługę GraphQL jako część swojej infrastruktury, ale jaką to przybiera formę? Czy jest to cały serwer działający na własnym porcie? A może jest to po prostu biblioteka, którą integrujesz z istniejącym Express lub Apache lub czymkolwiek innym z trasą, która prowadzi do tej usługi? Jak to realizujesz?

Eve: Tak, to prawdziwy serwer. Tak więc najpopularniejszymi implementacjami GraphQL są serwery Node.js. Kiedy GraphQL został wydany jako specyfikacja, zespół wydał tę referencyjną implementację w JavaScript, rodzaj serwera Node, który służył jako wytyczne dla wszystkich innych, którzy się pojawili. Ale tak, możesz uruchomić te serwery na ich własnych instancjach. Możesz je umieścić na Lambdzie. Mamy więc Apollo Server Express, mamy Apollo Server Lambda; wszelkiego rodzaju różne typy implementacji, których możesz użyć do uruchomienia tej rzeczy.

Drew: Wspomniałeś krótko przed koncepcją schematu, który ma serwer.

Ewa: Tak.

Drew: To daje ci możliwość bardziej ścisłego opisania twoich typów niż tylko, wiesz, mapowanie nazwy do resolvera. Tam jest więcej zaangażowanych, prawda?

Ewa: Tak. Jest pełny język. Więc odwołałem się do specyfikacji i nie opisałem, co to jest. Sam GraphQL jest specyfikacją opisującą język zapytań i język definicji schematu. Więc ma swoją własną składnię. Ma własne zasady definiowania tych typów.

Eve: Kiedy używasz języka definicji schematu, w zasadzie używasz wszystkich funkcji tego języka do przemyślenia, jakie typy są częścią API? Jest to również miejsce, w którym definiujesz zapytania, mutacje, które są czasownikami, takie jak akcje, tworzenie loginu do konta, takie rzeczy. A nawet subskrypcje GraphQL, które są kolejną fajną rzeczą, GraphQL czasu rzeczywistego, który możesz zdefiniować bezpośrednio w Schema.

Eve: Więc tak, schemat jest naprawdę bardzo ważny. I myślę, że zapewnia nam to przyjemne egzekwowanie typów w całej naszej pełnej aplikacji Stack, ponieważ gdy tylko zaczniesz odbiegać od tych pól i od tych typów, zaczynasz widzieć błędy, co w tym przypadku jest dobre, ponieważ ty przestrzegamy zasad Schematu.

Drew: Czy jest jakieś skrzyżowanie tego z TypeScriptem? Czy istnieje między nimi jakaś synergia?

Ewa: Absolutnie. Więc jeśli jesteś osobą, która dużo mówi o GraphQL, czasami ludzie powiedzą Ci, że jest zły i podejdą do Ciebie publicznie, kiedy będziesz mógł to zrobić, i porozmawiają o tym, że GraphQL nie jest dobry. Ale często pomijają fajne rzeczy, które dostajesz od typów. Jeśli chodzi o synergię z TypeScript, absolutnie możesz automatycznie generować typy dla swojej aplikacji front-endowej, używając typów ze schematu. Jest to więc ogromna wygrana, ponieważ możesz nie tylko wygenerować go za pierwszym razem, co zapewnia doskonałą interoperacyjność z aplikacją front-endową, ale także, gdy coś się zmieni, możesz ponownie wygenerować typy, a następnie zbudować je, aby odzwierciedlić te zmiany. Więc tak, myślę, że te rzeczy naprawdę dobrze do siebie pasują, ponieważ typy zaczynają być swego rodzaju faktyczną regułą.

Eve: …by być swego rodzaju de facto regułą w JavaScript, ładnie do siebie pasują.

Drew: Wydaje się, że jest to rodzaj ciągłego motywu związanego ze sposobem, w jaki zaprojektowano TypeScript… to nie jest TypeScript, przepraszam. GraphQL został zaprojektowany tak, aby było dużo o sformalizowanie interakcji między front-endem a back-endem. I pojawia się jako rozwiązanie pomiędzy tworzeniem spójności i formalizacją tego, co do tej pory było dość kiepskim doświadczeniem z odpoczynkiem dla wielu ludzi. Jedną rzeczą, o której zawsze musimy pamiętać podczas pisania aplikacji po stronie klienta, jest to, że kod podlega kontroli i ewentualnej modyfikacji. A posiadanie interfejsu API, w którym klient może po prostu zażądać danych, może być niebezpieczne. Teraz, jeśli możesz określić, jakie pola chcesz, może to być niebezpieczne. Gdzie w całym stosie miałbyś do czynienia z autoryzacją użytkowników i upewnieniem się, że reguły biznesowe wokół Twoich danych są egzekwowane?

Eve: Poradzisz sobie z tym wszystkim na serwerze. Tak więc może się to zdarzyć na wiele różnych sposobów. Nie musisz używać jednorazowej strategii, ale Twoje przeliczniki zajmą się Twoją autoryzacją. Może to oznaczać zawijanie istniejącego interfejsu API REST, takiego jak usługa taka jak Auth0 lub coś, co zbudowałeś samodzielnie. Może to oznaczać interakcję z OAuth, taką jak GitHub, Facebook lub logowanie Google, tego typu rzeczy, które wiążą się z przekazywaniem tokenów tam iz powrotem za pomocą programów rozpoznawania nazw. Ale często będzie to wbudowane bezpośrednio w Schemat. Więc schemat powie, nie wiem, stworzymy mutację logowania. Następnie wysyłam tę mutację z moimi danymi uwierzytelniającymi, a następnie na serwerze wszystkie te dane uwierzytelniające są weryfikowane. Więc klient nie musi się tak bardzo martwić, może trochę przekazywać tokeny i tym podobne. Ale większość z nich jest po prostu wbudowana w serwer.

Drew: Zasadniczo nie zmienia się to w porównaniu z tym, jak obecnie budujemy punkty końcowe odpoczynku. Reszta jako technologia, cóż, tak naprawdę nie zajmuje się ona również autoryzacją, a na serwerze mamy oprogramowanie pośredniczące i rzeczy, które się tym zajmują. I tak samo jest z GraphQL. Po prostu sobie z tym radzisz. Czy są jakieś konwencje w społeczności GraphQL, aby to robić? Czy istnieją wspólne podejścia, czy też jest wszędzie, w jaki sposób ludzie decydują się na ich wdrożenie?

Eve: Szczerze, jest wszędzie. Myślę, że w większości przypadków zobaczysz, jak ludzie wbudowują się w schemat i mam na myśli reprezentowanie tych typów i autoryzowanych użytkowników w porównaniu do zwykłych użytkowników, którzy wbudowują te typy w sam schemat. Ale zobaczysz też wiele osób korzystających z rozwiązań innych firm. Wspomniałem o Auth0. Wielu ludzi przerzuca swoją autoryzację na firmy, które są bardziej na tym skoncentrowane, zwłaszcza na mniejsze firmy, start-upy i tego typu rzeczy. Ale zobaczysz również, że większe firmy zaczynają tworzyć rozwiązania w tym zakresie. Tak więc AWS, Amazon ma AppSync, który jest ich smakiem GraphQL, i ma wbudowane role autora bezpośrednio w AppSync. I to jest całkiem fajne, po prostu móc, nie wiem, nie martwić się o te wszystkie rzeczy lub przynajmniej zapewnić interfejs do pracy z tym. Tak więc wiele z tych narzędzi ekosystemowych ma, myślę, że autoryzacja jest tak dużym tematem w GraphQL. Widzieli potrzebę, zapotrzebowanie na rozwiązania uwierzytelniania i standardowe podejście do obsługi uwierzytelniania na wykresie.

Drew: Wydaje mi się, że prawie nie ma implementacji, która nie wymaga jakiejś autoryzacji. Więc tak, będzie to dość powszechny wymóg. Wszyscy w coraz większym stopniu tworzymy aplikacje oparte na komponentach, szczególnie gdy używamy funkcji React i View oraz tego, co masz. A zasada luźnego sprzężenia pozostawia nam wiele komponentów, które niekoniecznie wiedzą, co jeszcze dzieje się na stronie wokół nich. Czy istnieje w związku z tym niebezpieczeństwo, że wiele komponentów będzie pytać o te same dane i wysyłać wiele żądań? A może to tylko problem architektoniczny w Twojej aplikacji, który musisz w tym celu rozwiązać? Czy istnieją jakieś dobrze utarte rozwiązania, aby sobie z tym poradzić?

Eve: Cóż, myślę, że GraphQL w większości nie 100% rozwiązań, ale prawie każde zapytanie GraphQL jest wysyłane przez HTTP. Więc jeśli chcesz wyśledzić, gdzie dzieje się te wiele żądań, prawdopodobnie jest to dość znany problem dla osób, które używają danych resztowych w swoich aplikacjach. Są więc narzędzia, takie jak Paulo Client Dev Tools i Urkel Dev Tools dla programistów front-end, którzy pytają: „Co się dzieje? Jakie zapytania znajdują się na tej stronie?” To daje naprawdę jasny wgląd w to, co się dzieje. Jest w tym kilka szkół myślenia. Czy tworzymy jedno duże, ogromne zapytanie dla wszystkich danych dla strony? A może tworzymy mniejsze zapytania w celu załadowania danych dla różnych części aplikacji? Oba, jak możesz sobie wyobrazić, mają swoje wady, ponieważ jeśli masz duże zapytanie, czekasz na więcej pól.

Eve: Jeśli masz mniejsze zapytania, mogą wystąpić kolizje między wymaganymi danymi. Ale myślę, żeby nie odchodzić za bardzo styczną, ale już tam jestem. Tak więc jest coś, co nazywa się dyrektywą odroczoną, która pojawia się w specyfikacji GraphQL, a dyrektywa odroczona ma pomóc przy wtórnym ładowaniu treści. Załóżmy więc, że u góry strony masz jakąś treść, bardzo ważną treść, którą chcesz najpierw załadować. Jeśli dodasz to do zapytania, a następnie wszystkie kolejne pola otrzymają odroczoną dyrektywę na ten temat. To tylko mały dekorator, który można dodać do pola, a następnie powie: „W porządku, najpierw załaduj ważne dane, a potem zatrzymaj i załaduj drugie dane”. W pewnym sensie daje to wrażenie przesyłania strumieniowego danych do interfejsu użytkownika, dzięki czemu jest postrzegana wydajność, jest interaktywność. Ludzie widzą dane od razu, zamiast czekać na załadowanie każdego pola na stronie, co może być problemem.

Drew: Tak. Domyślam się, że to pozwala ci zaprojektować strony, na których wszystko, co jest… nie lubimy mówić za dużo o widoku, ale to wszystko powyżej części zgięcia, możesz ustalić priorytety, załadować to, a następnie wczytać wszystko dalej. na dół. Tak więc dużo mówiliśmy o zapytaniach o dane. Jednym z głównych zadań API jest wysyłanie nowych i zmodyfikowanych danych z powrotem na serwer w celu utrwalenia. Wcześniej wspomniałeś krótko o mutacjach. To jest terminologia, której GraphQL używa do zapisywania danych z powrotem na serwer?

Ewa: Dokładnie. Więc jakiekolwiek zmiany, które chcemy wprowadzić do danych, wszystko, co chcemy zapisać z powrotem na serwerze, to są mutacje, a to wszystko jest jak zapytania, są to nazwane operacje, które znajdują się na serwerze. Możesz więc zastanowić się, jakie są wszystkie rzeczy, które chcemy, aby nasi użytkownicy mogli robić? Reprezentuj tych z mutacjami. A potem znowu na serwerze, napisz wszystkie funkcje, które sprawiają, że to działa.

Drew: A czy to jest tak proste jak zapytanie o dane? Wywołanie mutacji jest równie łatwe?

Ewa: Tak. Jest to część języka zapytań. Wygląda prawie identycznie. Jedyna różnica polega na tym, że zapytania przyjmują filtry. Tak więc mutacje pobierały coś, co wyglądało jak filtry w samym zapytaniu. Ale to one są odpowiedzialne za rzeczywistą zmianę danych. E-mail i hasło mogą zostać wysłane z mutacją, a następnie serwer zbiera je, a następnie używa do autoryzacji użytkownika.

Drew: Tak jak poprzednio, tworzysz przelicznik na zapleczu, aby sobie z tym poradzić i zrobić wszystko, co trzeba. Jednym z typowych przypadków podczas pisania danych jest to, że chcesz zatwierdzić swoje zmiany, a następnie ponownie wykonać zapytanie, aby uzyskać rodzaj ich bieżącego stanu. Czy GraphQL ma do tego dobry przepływ pracy?

Eve: W pewnym sensie żyje w samej mutacji. Tak więc wiele razy podczas tworzenia schematu tworzysz operację mutacji. Zostanę przy logowaniu, pobieram e-mail i hasło. A sama mutacja coś zwróciła. Więc może zwrócić coś tak prostego jak Boolean, to poszło dobrze, to poszło źle, lub może zwrócić rzeczywisty typ. Tak często zobaczysz mutację jak mutację logowania, może zwraca użytkownika. Więc otrzymujesz wszystkie informacje o użytkowniku, gdy jest on zalogowany. Możesz też utworzyć niestandardowy typ obiektu, który daje temu użytkownikowi plus czas logowania się użytkownika i może trochę więcej metadanych dotyczących tej transakcji w obiekcie zwracanym . Więc znowu, od ciebie zależy, czy to zaprojektujesz, ale ten wzór jest tak naprawdę zapieczętowany w GraphQL.

Drew: To wszystko brzmi całkiem nieźle, ale każdy wybór techniczny wiąże się z kompromisami. Jakie są wady korzystania z GraphQL? Czy są jakieś scenariusze, w których byłby to naprawdę kiepski wybór?

Eve: Myślę, że miejscem, w którym GraphQL może mieć problemy, jest tworzenie mapy jeden-do-jednego-

Ewa: … trudność polega na tworzeniu mapy danych tabelarycznych jeden do jednego. Powiedzmy, że masz, nie wiem, myślę o tabeli bazy danych z różnymi rodzajami pól i, nie wiem, tysiącami pól określonego typu, takimi rzeczami, ten typ danych może być ładnie reprezentowany z GraphQL, ale czasami, gdy uruchamiasz proces generowania schematu na tych danych, pozostają w schemacie te same problemy, które miałeś w bazie danych, co może oznaczać zbyt dużo danych, które wykraczają poza to, co klient faktycznie wymaga. Myślę więc, że te miejsca są potencjalnymi problemami. Rozmawiałem z ludźmi, którzy automatycznie wygenerowali schematy na podstawie swoich danych i stał się schematem o długości miliona linii lub czymś w tym rodzaju, po prostu tysiącami wierszy kodu schematu. I tutaj staje się to trochę trudne, na przykład jak użyteczny jest ten dokument jako dokument czytelny dla człowieka?

Ewa: Tak. Tak więc każda sytuacja, w której masz do czynienia z klientem, jest naprawdę fajnie dopasowana, jeśli chodzi o modelowanie każdego typu danych, staje się trochę trudna, jeśli twoje źródła danych są zbyt duże.

Drew: Brzmi to tak, jakby wszędzie tam, gdzie będziesz starannie dobierać odpowiedzi na polach i robić to więcej ręcznie, możesz uzyskać naprawdę dobre wyniki. Ale jeśli automatycznie generujesz rzeczy, ponieważ właśnie masz ogromny schemat, może staje się to trochę nieporęczne.

Ewa: Tak. I myślę, że ludzie słuchają i nie zgadzają się ze mną, ponieważ są do tego dobre narzędzia. Ale myślę, że miejsce, w którym GraphQL naprawdę błyszczy, to ten krok abstrahowania logiki do serwera, dający programistom front-end swobodę definiowania ich komponentów lub wymagań dotyczących danych front-endów i naprawdę zarządzania Schema jako zespół.

Drew: Czy jest coś wbudowanego w język zapytań, aby poradzić sobie z podziałem na strony wyników, czy też jest to sprowadzane do niestandardowej implementacji w razie potrzeby?

Ewa: Tak. Paginacja, należy najpierw wbudować w Schemat, aby móc w tym celu zdefiniować paginację. W społeczności pojawiło się wiele wytycznych. Dobrym przykładem do obejrzenia, jeśli jesteś nowszy w GraphQL, czy nie, patrzę na to cały czas, jest GitHub GraphQL API. Zasadniczo odtworzyli swoje API dla v4 ich publicznego API przy użyciu GraphQL. To dobre miejsce, aby przyjrzeć się, jak naprawdę duża firma używa tego na dużą skalę. Wiele osób ma uruchomione duże interfejsy API, ale nie udostępniają ich wszystkim. Tak więc paginacja jest naprawdę dobrze wbudowana w to API i możesz zwrócić, nie wiem, pierwszych 50 repozytoriów, które kiedykolwiek utworzyłeś, lub możesz również użyć paginacji opartej na kursorach do zwracania rekordów opartych na pomysłach w twoich danych. Tak więc paginacja oparta na kursorze i rodzaj paginacji pozycyjnej, jak pierwsza, ostatnia płyta, zazwyczaj tak ludzie podchodzą do tego, ale jest wiele technik.

Drew: Czy są jakieś duże problemy, o których powinniśmy wiedzieć, używając GraphQL? Powiedzmy, że mam zamiar wdrożyć nową instalację GraphQL dla mojej organizacji, będziemy budować wszystkie nasze nowe punkty końcowe API przy użyciu GraphQL w przyszłości. Co powinienem wiedzieć? Czy w krzakach coś się czai?

Eve: Czai się w krzakach, zawsze z technologią, prawda? Myślę, że jedną z rzeczy, które nie są wbudowane w GraphQL, ale można je zaimplementować bez większych problemów, jest bezpieczeństwo API. Na przykład wspomniałeś, że jeśli mam ogromne zapytanie, rozmawialiśmy o tym z autoryzacją, ale przerażające jest również otwieranie interfejsu API, w którym ktoś mógłby po prostu wysłać ogromne zapytanie zagnieżdżone, znajomi znajomych, znajomi znajomych, znajomi znajomych , w dół iw dół łańcucha. A potem w zasadzie pozwalasz ludziom DDoS cię za pomocą tych ogromnych zapytań. So there's things that you can set up on the server to limit query depth and query complexity. You can put queries on a safe list. So maybe your front ends, you know what they all are and it's not a public API. So you only want to let certain queries come over the wire to you. So I would say before rolling that out, that is definitely a possible gotcha with the GraphQL.

Drew: You do a lot of instruction and training around GraphQL, and you've co-written the O'Reilly 'animal' book with Alex Banks called Learning GraphQL. But you've got something new that you're launching early in 2021, is that right?

Eve: That's right. So I have been collaborating with egghead.io to create a full stack GraphQL video course. We're going to build an API and front end for a summer camp, so everything is summer camp themed. And yeah, we're just going to get into how to work with Apollo server, Apollo client. We will talk about scaling GraphQL APIs with Apollo Federation. We'll talk about authorization strategies and all sorts of different things. So it's just kind of collecting the things that I've learned from teaching over the past, I don't know, three or four years GraphQL and putting it into one spot.

Drew: So it's a video course that… Is it all just self-directed, you can just work your way through at your own pace?

Eve: Yeah, exactly. So it's a big hefty course so you can work through it at your own pace. Absolutnie.

Drew: Oh, that sounds really good. And it's graphqlworkshop.com, is that right?

Eve: Graphqlworkshop.com, exactly.

Drew: And I'm looking forward to seeing that released because I think that's something that I might need. So I've been learning all about GraphQL. What have you been learning about lately?

Eve: I've also been looking into Rust lately. So I've been building a lot of Rust Hello Worlds, and figuring out what that is. I don't know if I know what that is yet, but I have been having fun tinkering around with it.

Drew: If you dear listener, would like to hear more from Eve, you can find her on Twitter where she's @eveporcello, and you can find out about her work at moonhighway.com. Her GraphQL workshop, discover your path through the GraphQL wilderness, is coming out early in 2021 and can be found at graphqlworkshop.com. Thanks for joining us today, Eve. Czy masz jakieś pożegnalne słowa?

Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.