Smashing Podcast Episodul 31 cu Eve Porcello: Ce este GraphQL?

În acest episod, vorbim despre GraphQL. Ce este și cum se rezolvă unele probleme comune ale API-ului? Am vorbit cu experta Eve Porcello pentru a afla.

Afișați note

• Eve pe Twitter
• Compania lui Eve, Moon Highway
• Învățarea GraphQL de la O'Reilly
• Discover Your Path Through The GraphQL Wilderness - Atelierul GraphQL al lui Eve care se lansează la începutul anului 2021

Actualizare săptămânală

• Cum să utilizați MDX stocat în Sanity într-un site web Next.js
  scris de Jason Lengstorf
• Construirea unui chatbot compatibil NLP conversațional folosind fluxul de dialog Google
  scris de Nwani Victory
• Considerații etice în cercetarea UX: Nevoia de instruire și revizuire
  scris de Victor Yocco
• Faceți site-urile web mai ușor de discutat
  scris de Frederick O'Brien
• Cum să proiectați o interfață de utilizare simplă când aveți o soluție complexă
  scris de Suzanne Scacca

Transcriere

Drew McLellan: Ea este inginer software, instructor, autoare și co-fondatoare a companiei de formare și dezvoltare de curriculum, Moon Highway. Cariera ei a început să scrie specificații tehnice și să creeze design UX pentru proiecte web. De când a început Moon Highway în 2012, ea a creat conținut video pentru egghead.io și LinkedIn Learning și a fost coautor al cărților Learning React și Learning GraphQL pentru O'Reilly's Media.

Drew: Ea este, de asemenea, un vorbitor frecvent la conferințe și a prezentat la conferințe, inclusiv React Rally, GraphQL Summit și OSCON. Deci știm că este o expertă în GraphQL, dar știai că a învățat odată un urs polar să joace șah? Prietenii mei zdrobitori, vă rog bun venit Eve Porcello.

Drew: Bună Eve, ce mai faci?

Eve Porcello: Sunt zdrobitoare.

Drew: După cum am menționat acolo, ești foarte educator în lucruri precum JavaScript și React, dar am vrut să-ți vorbesc astăzi despre una dintre celelalte domenii de specialitate ale tale, GraphQL. Mulți dintre noi vor fi auzit de GraphQL într-o anumită calitate, dar s-ar putea să nu fie complet siguri ce este sau ce face și, în special, ce fel de problemă rezolvă în stiva web.

Drew: Așa că pregătește scena pentru noi, dacă vrei, dacă sunt un dezvoltator front end, unde intră GraphQL în ecosistem și ce funcție îndeplinește pentru mine?

Eve: Da. GraphQL se potrivește între partea din față și cea din spate. Este un fel de a trăi la mijloc între cele două și oferă o mulțime de beneficii dezvoltatorilor front-end și dezvoltatorilor back-end.

Eve: Dacă sunteți un dezvoltator front-end, puteți defini toate cerințele dvs. de date front-end. Deci, dacă aveți o listă mare de componente React, de exemplu, puteți scrie o interogare. Și asta va defini toate câmpurile de care ați avea nevoie pentru a completa datele pentru pagina respectivă.

Eve: Acum, cu partea de backend, este cu adevărat proprie, pentru că putem colecta o mulțime de date din o mulțime de surse diferite. Deci avem date în API-uri REST și baze de date și toate aceste locuri diferite. Și GraphQL ne oferă acest mic strat frumos de orchestrare pentru a înțelege cu adevărat haosul în care se află toate datele noastre. Deci este foarte util pentru toată lumea din toată stiva.

Drew: Deci este practic o tehnologie bazată pe API, nu-i așa? Se află între front-end și back-end și oferă un fel de API, este corect?

Eve: Da, exact așa este. Exact.

Drew: Cred că, în ultimul deceniu, standardul de aur pentru API-uri a fost odihna. Deci, dacă aveți o aplicație pe partea clientului și trebuie să o completați cu date din backend, ați construi un punct final API REST și ați interoga asta. Deci, unde cade modelul? Și când am putea avea nevoie de GraphQL să vină și să rezolve asta pentru noi?

Eve: Ei bine, problema cu care ne ajută GraphQL cu adevărat, un fel de problemă de aur, soluția de aur, cred că o oferă GraphQL este că, cu REST, am depășit preluarea multor date. Deci, dacă am utilizatori slash sau produse slash, asta îmi va da înapoi toate datele de fiecare dată când voi atinge ruta.

Eve: Cu GraphQL, putem fi puțin mai pretențioși în ceea ce privește datele pe care le dorim. Deci, dacă am nevoie doar de patru câmpuri dintr-un obiect care are o sută, voi fi capabil să identific acele câmpuri cu adevărat și nu trebuie să încarc datele sau să încarc toate acele date, ar trebui să spun, în dispozitivul dvs., deoarece este multă muncă suplimentară, în special pentru telefonul tău.

Drew: Am văzut și am lucrat cu API-uri REST în trecut care au un câmp opțional în care puteți trece o listă cu datele pe care le doriți înapoi sau puteți mări ceea ce revine cu lucruri suplimentare. Și cred că asta înseamnă identificarea acestei probleme, nu-i așa? Asta înseamnă că nu vrei întotdeauna aceleași date înapoi de fiecare dată. Deci GraphQL formalizează acea abordare de a permite front-end-ului să specifice ce va returna backend-ul, în termeni de date?

Eve: Da, exact. Deci, interogarea dvs. devine apoi modul în care întrebați, cum filtrați, cum înțelegeți orice fel de informații de oriunde.

Eve: De asemenea, cred că este important să remarcăm că nu trebuie să distrugem toate API-urile noastre REST pentru a lucra cu GraphQL cu adevărat. Multe dintre cele mai de succes implementări ale GraphQL pe care le-am văzut acolo, sunt învăluiri în jurul API-urilor REST. Și interogarea GraphQL vă oferă într-adevăr o modalitate de a vă gândi la ce date aveți nevoie. Și atunci poate că unele dintre datele tale provin de la utilizatorii și produsele noastre, exemple, unele dintre date provin de la REST, unele provin dintr-o bază de date.

Drew: Cred că scenariul familiar este că s-ar putea să aveți un punct final pe site-ul dvs. care returnează informații despre un utilizator pentru a afișa antetul. S-ar putea să vă ofere numele de utilizator și avatarul lor. Și le elimini pe fiecare pagină și populezi datele, dar apoi găsești în altă parte în aplicația ta în care trebuie să le afișezi numele complet.

Drew: Așa că adăugați asta la punctul final și începe să returneze asta. Și apoi vă faceți secțiunea de gestionare a contului și aveți nevoie de adresa lor poștală. Deci, acesta este returnat și de acel punct final.

Drew: Și înainte să vă dați seama, acel punct final returnează o încărcătură utilă grea care costă destul de mult pe backend pentru a aduna și, evident, mult de descărcat.

Drew: Și asta a fost selectat pe fiecare pagină doar pentru a arăta un avatar. Deci, cred că acesta este genul de problemă care crește în timp, în care a fost atât de ușor să cazi, în special în echipele mari, că GraphQL, este peste această problemă. Știe cum să rezolve asta și este conceput în jurul rezolvării.

Eve: Exact. Și da, cred că întreaga idee a unei scheme GraphQL, cred că este într-adevăr, despre ea se vorbește mai puțin decât partea de limbaj de interogare a GraphQL. Dar chiar simt că Schema în special ne oferă acest tip de sistem frumos pentru API.

Eve: Așadar, oricine din echipă, manageri, dezvoltatori front-end, dezvoltatori back-end, oricine care are de-a face cu date cu adevărat se poate reuni, să se unească în jurul datelor pe care vrem de fapt să le furnizăm în acest API și apoi toată lumea știe care este sursa respectivă. Adevărul este că ei își pot construi propriile părți ale aplicației pe baza asta.

Eve: Așa că există câteva lucruri complicate de management Schema care vin și cu asta. Dar în ceea ce privește trecerea de la microservicii înapoi la monoliți, într-un fel facem asta, dar beneficiem în continuare de toate beneficiile care ne plac de la microservicii.

Drew: Și înțeleg corect că modul tipic de a configura un sistem GraphQL este că ai avea practic o singură rută, care este punctul final către care trimiți toate interogările, astfel încât să nu fii nevoit să... Adesea, unul dintre Cel mai dificil lucru este să găsești ce să numești și care ar trebui să fie calea la care ar trebui să fie această interogare specială. Sunt utilizatori și produse care revin, ar trebui să reducă ceva utilizatorii sau să reducă ceva pe produs?

Drew: Cu GraphQL, aveți doar un punct final la care trimiteți interogările și primiți un răspuns adecvat.

Eve: Exact. Da. Este un singur punct final. Bănuiesc că încă mai aveți de-a face cu probleme de denumire, deoarece numiți totul în Schemă. Dar în ceea ce privește, mă simt ca o mulțime de companii care au făcut pariuri mari pe microservicii, toată lumea spune, ce puncte finale avem? Unde sunt? Cum sunt documentate? Și cu GraphQL, avem un singur loc, un fel de dicționar pentru a căuta orice dorim să aflăm despre cum funcționează API-ul.

Drew: Așadar, sunt foarte familiarizat cu alte limbaje de interogare, cum ar fi SQL-ul este un exemplu evident de limbaj de interogare pe care mulți dezvoltatori web îl vor cunoaște. Iar interogările din acestea iau forma aproape ca o comandă. Este un șir de text, nu-i așa? Selectați asta din aia, unde, orice. Ce format au interogările cu GraphQL?

Eve: Este încă un șir de tehnologie, dar nu definește de unde vine acea logică. Și o mare parte din logică este mutată înapoi pe server. Așadar, serverul GraphQL, API-ul GraphQL este cu adevărat responsabil pentru a spune: „Du-te și adu aceste date de unde sunt, filtrează-le pe baza acestor parametri.”

Eve: Dar în limbajul de interogare, este foarte orientat spre câmp. Așa că doar adăugăm câmpuri pentru orice dorim să recuperăm. Putem pune filtre și pentru acele interogări, desigur. Dar cred că este puțin mai puțin direct de unde provin acele informații. O mare parte din funcționalitate este încorporată în server.

Drew: Deci, puteți amesteca și potrivi într-o interogare. Puteți face o solicitare care aduce înapoi o mulțime de tipuri diferite de date într-o singură solicitare. Este corect?

Eve: Da, este absolut corect. Deci, puteți trimite o interogare pentru câte câmpuri ar permite serverul dvs. și puteți aduce înapoi tot felul de date imbricate. Dar așa funcționează, conectăm diferite tipuri pe câmpuri. Așadar, cred că îmi vom recicla utilizatorii și ideea de produse, dar utilizatorul ar putea avea un câmp de produse care returnează o listă de produse. Toate acestea sunt asociate și cu alte tipuri. Deci, oricât de adânc imbricat ne dorim ca interogarea să meargă, putem.

Drew: Asta înseamnă să regăsiți datele pentru o vizualizare tipică în aplicația dvs. web, care ar putea avea tot felul de lucruri care se întâmplă, încât să puteți face o singură cerere către backend și să le obțineți într-o singură mișcare, fără a fi nevoie să faceți diferite interogări către puncte finale diferite, pentru că totul este doar un singur lucru?

Eve: Da. Acesta este exact întregul obiectiv, este doar o singură interogare, definiți fiecare câmp pe care îl doriți și apoi returnați-l într-un singur răspuns.

Drew: Și interogările sunt bazate pe JSON, nu-i așa?

Eve: interogarea în sine este un șir de text, dar de obicei returnează date JSON. Deci, dacă am câmpurile, atunci răspunsul meu JSON se potrivește exact și este foarte clar ce primești atunci când trimiteți acea interogare, deoarece răspunsul la date arată exact la fel.

Drew: Multe dintre interogări se pare că sunt pentru aproape obiecte goale, cum ar fi un client sau un produs. Există o modalitate de a specifica interogări mai complexe în care logica de afaceri este controlată la backend? Să presupunem că vreau să obțin o listă de echipe pentru un utilizator, dar numai acolo unde acel utilizator este administratorul unei echipe și în care planul de echipă nu a expirat și toate acele tipuri de constrângeri reale cu care ne confruntăm în dezvoltarea de zi cu zi a aplicațiilor web. Acest lucru se poate realiza cu GraphQL?

Eve: Absolut. Deci, acesta este adevăratul lucru interesant și puternic despre GraphQL este că puteți muta o mare parte din acea logică pe server. Dacă ați avea o interogare complexă, un tip de utilizator cu adevărat specific pe care doriți să-l obțineți, tot ce trebuie să faceți în Schemă este să spuneți „Obțineți utilizator complicat”, iar apoi pe server ar exista o funcție în care ai putea scrie toată logica în orice limbă ai vrea. JavaScript este un fel de cel mai popular limbaj de implementare GraphQL, dar nu trebuie să îl utilizați deloc. Deci, Python, Go, C++, orice doriți să utilizați, puteți construi un server GraphQL cu asta. Dar da, puteți defini o interogare la fel de complexă pe cât doriți.

Drew: Și cred că asta vă permite să încapsulați o mulțime de logică de afaceri apoi în noi tipuri de obiecte. Este corect? Știi, ai configurat un utilizator complicat și apoi nu trebuie să te gândești ce este un utilizator complicat, dar poți să continui să folosești acel utilizator complicat și să știi că logica de afaceri este implementată pe asta. Este corect?

Eve: Exact asa. Așa că cred că acest lucru este foarte frumos pentru cei din front end, deoarece pot începe să prototipeze pe baza asta. Și apoi echipa backend ar putea să implementeze acele funcții pentru a face ca acestea să funcționeze. Și apoi există un fel de înțelegere comună pentru ceea ce este de fapt acel tip și cine sunt ei și, „Care sunt câmpurile de pe acel tip?” Și totul poate fi gestionat de oriunde funcționează GraphQL din stivă. Și de aceea nu este chiar o tehnologie front-end sau back-end. Este într-adevăr un fel de ambele, și nici unul.

Drew: Se pare că este un fel de oficializare a API-ului și a relației dintre front-end și backend, astfel încât toată lumea obține o interfață previzibilă care este standardizată.

Eve: Exact.

Drew: Ceea ce cred că în organizațiile în care front-end-ul și backend-ul sunt deținute de echipe diferite, ceea ce nu este deloc neobișnuit, cred că această abordare permite, de asemenea, să se facă modificări, să zicem, pe front-end, ar putea necesita diferite date, fără a avea nevoie de cineva care lucrează pe backend pentru a face modificările care corespund. Încă aveți acest API aproape infinit personalizabil, fără a fi nevoie de nicio muncă pentru a-l schimba dacă aveți nevoie de date noi.

Eve: Da, exact corect.

Drew: Deci serverul GraphQL este responsabil pentru formatarea răspunsului sau trebuie să faceți asta în logica de pe partea serverului?

Eve: Deci serverul GraphQL definește două lucruri. Definește schema în sine care trăiește pe server și apoi definește funcțiile de rezoluție. Acestea sunt funcții care preiau datele de oriunde s-ar afla. Deci, dacă am un API REST pe care îl împachetez cu GraphQL, rezolutorul ar prelua din acel API, va transforma datele așa cum ar trebui să fie și apoi le-ar returna clientului în acea funcție. Puteți utiliza orice fel de funcții de bază de date pe care doriți să le utilizați și pe acel server. Deci, dacă aveți date într-o grămadă de locuri diferite, acesta este un loc foarte frumos pentru a pune toate acele date și pentru a proiecta toată logica din jur, „Unde vin acele date? Cum vrem să-l transformăm?”

Drew: Clientul spune „Vreau un utilizator complex”, serverul îl primește într-o interogare și ar putea spune „Bine, voi căuta soluția de utilizator complexă”. Este corect?

Eve: Mm-hmm (afirmativ).

Drew: Care este funcția, apoi scrieți logica dvs. pentru ca echipa dvs. de backend, sau oricine scrie logica în interiorul acelei funcții, să facă tot ce este necesar pentru a returna un utilizator complex.

Eve: Da, exact.

Drew: Ar putea fi apelarea altor API-uri, ar putea fi interogarea unei baze de date, ar putea căuta lucruri în cache sau aproape orice.

Eve: Aproape orice. Și apoi, atâta timp cât acea întoarcere din funcție se potrivește cu cerințele Schemei, se potrivește cu ce câmpuri, ce tipuri au revenit acolo, atunci totul va funcționa frumos și armonios.

Drew: Bănuiesc că îți oferă un format de răspuns consecvent în întregul tău API doar implicit. Nu trebuie să proiectați cum arată. Doar obțineți un rezultat consistent.

Eve: Da, exact.

Drew: Cred că ar putea fi cu adevărat o victorie, pentru că poate fi foarte dificil să menții coerența într-o gamă largă de puncte finale API, în special în echipele mai mari. Oameni diferiți lucrează la lucruri diferite. Dacă nu aveți o guvernare destul de strictă, poate deveni foarte complex foarte repede, nu-i așa?

Eve: Da, absolut. Și cred că Schema este un document atât de drăguț pentru a descrie totul. Obțineți beneficiul automat de a putea vedea toate câmpurile din schema respectivă ori de câte ori încercați să îi trimiteți interogări, deoarece puteți trimite interogări de introspecție și există tot felul de instrumente frumoase pentru asta, cum ar fi GraphQL și GraphQL Playground, instrumente mici pe care le puteți folosi pentru a interacționa cu datele API-ului.

Eve: Dar, de asemenea, dacă te-ai jucat vreodată cu Postman, cum să faci ping la un API REST, multe dintre ele, documentația nu există cu adevărat sau este greu de găsit, sau lucruri de genul ăsta. GraphQL vă oferă cu adevărat acel strat coeziv frumos pentru a descrie tot ceea ce ar putea face parte din acel API.

Drew: Practic, cum funcționează lucrurile pe partea de server? Adică, cred că trebuie să rulezi un serviciu GraphQL ca parte a infrastructurii tale, dar ce formă ia asta? Este un server întreg care rulează pe propriul port? Sau este la fel ca o bibliotecă pe care o integrezi în Express sau Apache existent sau orice altceva cu o rută care se rezolvă la acel serviciu? Cum o implementezi?

Eve: Da, este un server real. Deci, cele mai populare implementări GraphQL sunt serverele Node.js. Când a fost lansat GraphQL ca specificație, echipa a lansat această implementare de referință în JavaScript, un fel de server Node care a servit drept ghid pentru toate celelalte care au apărut. Dar da, puteți rula aceste servere pe propriile instanțe. Le poți pune pe Lambda. Deci există Apollo Server Express, există Apollo Server Lambda; tot felul de tipuri diferite de implementări pe care le puteți folosi pentru a rula efectiv acest lucru.

Drew: Deci ați menționat pe scurt înainte conceptul de Schemă pe care îl are serverul.

Eve: Da.

Drew: Asta îți oferă abilitatea de a-ți descrie tipurile mai strict decât doar, știi, maparea unui nume la un resolver. Sunt mai implicați acolo, nu-i așa?

Eve: Da. Există un limbaj complet. Așa că am făcut referire la specificații și nu am descris ce este. GraphQL în sine este o specificație care descrie limbajul de interogare și limbajul de definire Schema. Deci are propria sa sintaxă. Are propriile reguli pentru definirea acestor tipuri.

Eve: Când utilizați limbajul de definire Schema, utilizați practic toate caracteristicile acelui limbaj pentru a vă gândi la care sunt tipurile care fac parte din API? De asemenea, aici definiți interogările, mutațiile, care sunt verbele, precum acțiunile, creați autentificare în cont, lucruri de genul ăsta. Și chiar și abonamentele GraphQL, care sunt un alt lucru cool, GraphQL în timp real, pe care îl puteți defini chiar acolo în Schemă.

Eve: Deci da, Schema este foarte importantă. Și cred că ne oferă acest tip de aplicare frumos în aplicația noastră completă Stack, deoarece de îndată ce începi să devii de la acele câmpuri și de la acele tipuri, începi să vezi erori, ceea ce este, în acest caz, bine, deoarece urmați regulile Schemei.

Drew: Există vreun crossover între asta și TypeScript? Există un fel de sinergie între cei doi acolo?

Eve: Absolut. Deci, dacă ești o persoană care vorbește mult despre GraphQL, uneori oamenii îți vor spune că este rău și vor veni la tine public, când poți face asta, și vorbesc despre cum GraphQL nu este bun. Dar de multe ori ei omit lucrurile interesante pe care le obțineți de la tipuri. Deci, în ceea ce privește sinergia cu TypeScript, absolut, puteți genera automat tipuri pentru aplicația dvs. frontală folosind tipurile din Schemă. Deci, acesta este un câștig uriaș, deoarece nu îl puteți genera doar prima dată, ceea ce vă oferă o interoperabilitate excelentă cu aplicația dvs. frontală, ci și, pe măsură ce lucrurile se schimbă, puteți regenera tipurile și apoi creați pentru a reflecta acele modificări. Deci da, cred că acele lucruri se potrivesc foarte bine împreună, deoarece tipurile încep să fie un fel de regula de facto.

Eve: … ca să fie un fel de regulă de facto în JavaScript, se potrivesc bine împreună.

Drew: Pare a fi un fel de temă în curs de desfășurare cu felul în care a fost proiectat TypeScript... nu este TypeScript, îmi pare rău. GraphQL a fost proiectat astfel încât există multe despre formalizarea interacțiunii dintre front-end și back-end. Și vine ca o soluție între doar creează consistență și o formalizare a ceea ce până acum a fost o experiență destul de neplăcută cu odihnă pentru mulți oameni. Un lucru pe care trebuie să-l ținem mereu cont atunci când scriem aplicații pe partea clientului este că codul este supus inspecției și eventual modificări. Și a avea un API în care clientul poate solicita doar date ar putea fi periculos. Acum, dacă puteți specifica ce câmpuri doriți, poate că ar putea fi periculos. Unde, în felul întregii stive, v-ați ocupa de autorizarea utilizatorilor și de a vă asigura că regulile de afaceri din jurul datelor dvs. sunt aplicate?

Eve: Te-ai ocupa de asta pe server. Deci, asta s-ar putea întâmpla în multe moduri diferite. Nu trebuie să utilizați o strategie unică, dar rezolutorii dvs. se vor ocupa de autorizarea dvs. Deci, asta ar putea însemna încheierea unui API REST existent, cum ar fi un serviciu precum Auth0 sau ceva pe care l-ați construit pe cont propriu. Asta ar putea însemna interacțiunea cu un OAuth, cum ar fi GitHub sau Facebook sau Google login, acele tipuri de lucruri care implică un fel de transmitere de token-uri înainte și înapoi cu soluții. Dar de multe ori acestea vor fi integrate direct în Schemă. Deci Schema va spune, nu știu, vom crea o mutație de conectare. Și apoi trimit acea mutație cu acreditările mele și apoi pe server, toate acele acreditări sunt verificate. Așa că clientul nu trebuie să-și facă atâtea griji, poate un pic de jetoane de trecere și lucruri de genul ăsta. Dar cea mai mare parte este doar încorporată în server.

Drew: Deci, în esență, asta nu se schimbă cu adevărat în comparație cu modul în care construim puncte finale de odihnă în acest moment. Odihnește-te ca tehnologie, ei bine, nici nu prea se ocupă de autorizare și avem middleware și lucruri pe server care se ocupă de asta. Și este la fel și cu GraphQL. Tu doar te descurci cu asta. Există convenții în comunitatea GraphQL pentru a face asta? Există abordări comune sau este peste tot modul în care oamenii aleg să o implementeze?

Eve: Sincer, este peste tot. Cred că de cele mai multe ori veți vedea oameni construind în Schemă și prin asta vreau să spun, reprezentând acele tipuri și utilizatori autorizați față de utilizatori obișnuiți construind acele tipuri în Schemă în sine. Dar veți vedea, de asemenea, o mulțime de oameni care folosesc soluții terțe. Am menționat Auth0. Mulți oameni își vor transfera autorizația către companiile care sunt mai concentrate pe asta, în special companiile mai mici, startup-urile, lucruri de genul ăsta. Dar veți vedea și companii mai mari care încep să creeze soluții pentru acest lucru. Deci, AWS, Amazon are AppSync, care este gustul lor de GraphQL, și au liste de autori integrate direct în AppSync. Și asta e grozav doar să poți, nu știu, să nu-ți faci griji pentru toate chestiile astea sau cel puțin să oferi o interfață pentru a lucra cu asta. Deci, multe dintre aceste instrumente ecosistemice au, cred că autorizarea este un subiect atât de mare în GraphQL. Au văzut un fel de nevoie, cererea de soluții de autentificare și abordări standard pentru gestionarea auth pe grafic.

Drew: Cred că aproape că există o implementare care să nu aibă nevoie de un fel de autorizare. Deci da, va fi o cerință destul de comună. Cu toții construim din ce în ce mai multe aplicații componente, în special atunci când folosim lucrurile React și View și ce ai tu. Iar principiul cuplajului liber ne lasă cu o mulțime de componente care nu știu neapărat ce mai rulează pe pagina în jurul lor. Există un pericol ca urmare a faptului că ați putea ajunge cu o mulțime de componente care solicită aceleași date și fac cereri multiple? Sau este doar o problemă arhitecturală din aplicația dvs. pe care trebuie să o rezolvați pentru asta? Există un fel de soluții bine bătute pentru a rezolva asta?

Eve: Ei bine, cred că pentru că GraphQL în cea mai mare parte, nu 100% dintre soluții, dar aproape fiecare interogare GraphQL este trimisă prin HTTP. Deci, dacă doriți să urmăriți unde au loc acele solicitări multiple, probabil că este o problemă destul de familiară pentru cei care folosesc datele de odihnă pentru aplicațiile lor. Deci, există unele instrumente precum Paulo Client Dev Tools și Urkel Dev Tools pentru dezvoltatorii front-end care spun: „Ce se întâmplă? Ce întrebări sunt pe această pagină?” Asta vă oferă o perspectivă foarte clară asupra a ceea ce se întâmplă. Există mai multe școli de gândire cu asta. Creăm o interogare mare, uriașă pentru toate datele pentru pagină? Sau creăm interogări mai mici pentru a încărca date pentru diferite părți ale aplicației? Ambele, după cum vă puteți imagina, au propriile lor dezavantaje, doar pentru că dacă aveți o interogare mare, așteptați mai multe câmpuri.

Eve: Dacă aveți interogări mai mici, pot exista coliziuni între datele pe care le solicitați. Dar cred, și să nu merg pe o tangentă prea mare, dar sunt deja acolo. Deci, există ceva numit directivă amânată care vine la specificațiile GraphQL și Directiva amânată va ajuta cu un fel de încărcare secundară a conținutului. Deci, să presupunem că aveți ceva conținut în partea de sus a paginii, conținutul super important pe care doriți să îl încărcați mai întâi. Dacă adăugați asta la interogarea dvs. și apoi orice câmpuri ulterioare primesc directiva amânată cu privire la aceasta. Este doar un mic decorator pe care l-ați adăuga într-un câmp, care va spune apoi: „Bine, încărcați mai întâi datele importante, apoi țineți apăsat și încărcați a doua date.” Și îți oferă acest lucru, este aspectul unui tip de date în flux la front-end, astfel încât să existe performanță percepută, există interactivitate. Oamenii văd datele imediat, comparativ cu așteptarea ca fiecare câmp să se încarce pentru pagină, ceea ce da, ar putea fi o problemă.

Drew: Da. Bănuiesc că asta vă permite să proiectați pagini în care tot ceea ce este... nu ne place să vorbim prea mult despre fereastra, dar este tot ce este deasupra pliului, ați putea să prioritizați, să aveți acea încărcare și apoi să încărcați în al doilea rând totul mai departe. jos. Deci, am vorbit mult despre interogarea datelor. Una dintre sarcinile principale ale unui API este trimiterea de date noi și modificate înapoi la server pentru persistență. Ai menționat pe scurt mutații mai devreme. Aceasta este terminologia pe care o folosește GraphQL pentru scrierea datelor înapoi pe server?

Eve: Exact. Deci orice fel de modificări pe care vrem să le facem datelor, orice vrem să scriem înapoi pe server, acestea sunt mutații și toate sunt exact ca interogări, sunt numite operațiuni care trăiesc pe server. Deci, vă puteți gândi care sunt toate lucrurile pe care vrem să le poată face utilizatorii noștri? Reprezentați-i pe cei cu mutații. Și apoi din nou pe server, scrieți toate funcțiile care fac ca lucrurile să funcționeze.

Drew: Și este la fel de simplu ca și interogarea datelor? Apelarea unei mutații este la fel de ușor?

Eve: Da. Face parte din limbajul de interogare. Arata aproape identic. Singura diferență este că, ei bine, cred că interogările au filtre. Deci, mutațiile au luat ceea ce păreau filtre în interogarea în sine. Dar aceștia sunt responsabili pentru schimbarea efectivă a datelor. Un e-mail și o parolă pot fi trimise cu o mutație, iar apoi serverul le colectează și apoi le folosește pentru a autoriza utilizatorul.

Drew: Deci, la fel ca înainte, creați un solutor pe backend pentru a se ocupa de asta și pentru a face tot ce trebuie făcut. O apariție obișnuită atunci când scrieți date este că doriți să efectuați modificările și apoi să reinterogați pentru a obține tipul de stare curentă a acestora. Are GraphQL un flux de lucru bun pentru asta?

Eve: Trăiește într-un fel în mutația însăși. Deci, de multe ori, atunci când vă creați Schema, veți crea operația de mutație. Voi rămâne cu autentificare, accept e-mailul și parola. Și mutația în sine a returnat ceva. Deci ar putea returna ceva la fel de simplu ca un boolean, acesta a mers bine, sau acesta a mers prost, sau ar putea returna un tip real. Așa că de multe ori veți vedea mutația ca mutația de conectare, poate returnează un utilizator. Așadar, obțineți toate informațiile despre utilizator odată ce acesta este conectat. Sau puteți crea un tip de obiect personalizat care vă oferă acel utilizator plus ora la care utilizatorul s-a autentificat și poate puțin mai multe metadate despre tranzacția respectivă în obiectul returnat. . Deci, din nou, depinde într-un fel de dvs. să proiectați asta, dar acel model este într-adevăr integrat în GraphQL.

Drew: Toate acestea sună destul de grozav, dar fiecare alegere tehnică implică compromisuri. Care sunt dezavantajele utilizării GraphQL? Există scenarii în care ar fi o alegere cu adevărat proastă?

Eve: Cred că locul în care un GraphQL s-ar putea lupta este crearea unei hărți unu-la-unu a...

Eve: … lupta este crearea unei hărți unu-la-unu a datelor tabelare. Deci, să presupunem că aveți, nu știu, gândiți-vă la un tabel de bază de date cu tot felul de câmpuri diferite și, nu știu, mii de câmpuri pe un anumit tip, lucruri de genul ăsta, acel tip de date poate fi reprezentat frumos cu GraphQL, dar uneori când rulezi un proces pentru a genera o Schemă pe acele date, rămâi cu, într-o Schemă, aceleași probleme pe care le-ai avut în baza de date, adică poate prea multe date care depășesc ceea ce clientul cere de fapt. Deci, cred că acele locuri, sunt potențiale probleme. Am vorbit cu oameni care au generat automat Scheme pe baza datelor lor și a devenit o Schemă de un milion de linii sau ceva de genul acesta, doar mii și mii de linii de cod Schema. Și acolo devine puțin complicat, cum ar fi cât de util este acesta ca document care poate fi citit de om?

Eve: Da. Deci, orice fel de situație în care aveți de-a face cu un client, este o potrivire foarte bună în ceea ce privește modelarea fiecărui tip diferit de date, devine puțin complicată dacă sursele dvs. de date sunt prea mari.

Drew: Așadar, sună ca oriunde unde vei organiza cu atenție răspunsurile în câmpuri și vei face mai mult manual, poți obține rezultate cu adevărat puternice. Dar dacă generați automat lucruri pentru că tocmai aveți o Schemă masivă, atunci poate devine puțin greu de manevrat.

Eve: Da. Și cred că oamenii mă ascultă și nu sunt de acord cu mine pentru că există instrumente bune și pentru asta. Dar cred că un fel de loc în care GraphQL strălucește cu adevărat este acel pas de abstractizare a logicii către server, oferind dezvoltatorilor front-end libertatea de a-și defini componentele sau cerințele lor de date front-end și gestionând cu adevărat Schema ca o echipă.

Drew: Există ceva încorporat în limbajul de interogare pentru a se ocupa de paginarea rezultatelor sau se reduce la o implementare personalizată, după cum este necesar?

Eve: Da. Paginare, veți construi mai întâi în Schemă, astfel încât să puteți defini paginarea pentru asta. Există o mulțime de linii directoare care au apărut într-un fel în comunitate. Un exemplu bun pe care să-l vedeți dacă sunteți mai nou la GraphQL sau nu, mă uit la asta tot timpul, este API-ul GitHub GraphQL. Practic, și-au recreat API-ul pentru v4 a API-ului lor public folosind GraphQL. Deci, acesta este un loc bun pentru a vedea cum o companie mare reală folosește acest lucru la scară. Mulți oameni au API-uri mari care rulează, dar nu le fac publice pentru toată lumea. Deci paginarea este încorporată în acel API foarte frumos și puteți returna, nu știu, primele 50 de depozite pe care le-ați creat vreodată, sau puteți utiliza și paginarea bazată pe cursor pentru a returna înregistrări bazate pe ideile din datele dvs. Deci, paginarea bazată pe cursor și un fel de paginare pozițională, cum ar fi prima, ultima înregistrare, așa este de obicei modul în care oamenii abordează asta, dar există multe tehnici.

Drew: Există probleme mari pe care ar trebui să le cunoaștem când folosim GraphQL? Să presupunem că sunt pe cale să implementez o nouă instalare GraphQL pentru organizația mea, vom construi toate noile noastre puncte finale API folosind GraphQL de acum înainte. Ce ar trebui să știu? Există ceva la pândă în tufișuri?

Eve: Pândind în tufișuri, mereu cu tehnologie, nu? Cred că unul dintre lucrurile care nu este încorporat în GraphQL, dar care poate fi implementat fără prea multe bătăi de cap este securitatea API. Deci, de exemplu, ați menționat că dacă am o interogare uriașă, am vorbit despre asta cu autorizare, dar este și înfricoșător să deschideți un API în care cineva ar putea trimite o interogare uriașă imbricată, prieteni ai prietenilor, prietenii prietenilor, prietenii prietenilor. , în jos și în jos pe lanț. Și apoi, practic, le permiteți oamenilor să vă DDoS cu aceste interogări uriașe. 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. Absolut.

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. Ai cuvinte de despărțire?

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