Smashing Podcast Episodio 31 Con Eve Porcello: cos'è GraphQL?

In questo episodio parliamo di GraphQL. Che cos'è e come risolve alcuni problemi API comuni? Ho parlato con l'esperta Eve Porcello per scoprirlo.

Mostra note

• Eva su Twitter
• La compagnia di Eve Moon Highway
• Imparare GraphQL da O'Reilly
• Scopri il tuo percorso attraverso la natura selvaggia di GraphQL - Il workshop GraphQL di Eve verrà lanciato all'inizio del 2021

Aggiornamento settimanale

• Come utilizzare MDX memorizzato nella sanità mentale in un sito Web Next.js
  scritto da Jason Lengstorf
• Creazione di un chatbot abilitato per la NLP conversazionale utilizzando Dialogflow di Google
  scritto da Nwani Victory
• Considerazioni etiche nella ricerca sulla UX: la necessità di formazione e revisione
  scritto da Victor Yocco
• Rendere i siti Web più facili con cui parlare
  scritto da Frederick O'Brien
• Come progettare un'interfaccia utente semplice quando si dispone di una soluzione complessa
  scritto da Suzanne Scacca

Trascrizione

Drew McLellan: È un'ingegnere del software, istruttrice, autrice e co-fondatrice della società di formazione e sviluppo del curriculum, Moon Highway. La sua carriera ha iniziato scrivendo specifiche tecniche e creando UX design per progetti web. Da quando ha iniziato Moon Highway nel 2012, ha creato contenuti video per egghead.io e LinkedIn Learning ed è coautrice dei libri Learning React e Learning GraphQL per O'Reilly's Media.

Drew: È anche una frequente oratrice di conferenze e ha presentato conferenze tra cui React Rally, GraphQL Summit e OSCON. Quindi sappiamo che è un'esperta di GraphQL, ma sapevi che una volta ha insegnato a un orso polare a giocare a scacchi? Miei formidabili amici, vi prego di dare il benvenuto a Eve Porcello.

Drew: Ciao Eve, come stai?

Eve Porcello: Sto distruggendo.

Drew: Come ho già detto, sei un vero educatore in cose come JavaScript e React, ma volevo parlarti oggi di una delle tue altre aree specialistiche, GraphQL. Molti di noi avranno sentito parlare di GraphQL in qualche modo, ma potrebbero non essere completamente sicuri di cosa sia o cosa faccia e, in particolare, che tipo di problema risolve nello stack web.

Drew: Quindi prepara le basi per noi, se vuoi, se sono uno sviluppatore front-end, dove si inserisce GraphQL nell'ecosistema e quale funzione svolge per me?

Eva: Sì. GraphQL si adatta tra il front-end e il back-end. È come vivere nel mezzo tra i due e offre molti vantaggi agli sviluppatori front-end e agli sviluppatori back-end.

Eve: se sei uno sviluppatore front-end, puoi definire tutti i tuoi requisiti di dati front-end. Quindi, se hai un grande elenco di componenti React, ad esempio, puoi scrivere una query. E questo definirà tutti i campi di cui avresti bisogno per popolare i dati per quella pagina.

Eve: Ora, con il pezzo di back-end, è davvero di proprietà, perché possiamo raccogliere molti dati da molte fonti diverse. Quindi abbiamo i dati nelle API REST, nei database e in tutti questi luoghi diversi. E GraphQL ci fornisce questo piccolo strato di orchestrazione per dare davvero un senso al caos di dove si trovano tutti i nostri dati. Quindi è davvero utile per tutti in tutto lo stack.

Drew: Quindi è fondamentalmente una tecnologia basata su API, vero? Si trova tra il front-end e il back-end e fornisce una sorta di API, è corretto?

Eve: Sì, è proprio così. Esattamente.

Drew: Penso che, nell'ultimo decennio, il gold standard per le API sia stato il riposo. Quindi, se disponi di un'app lato client e devi popolarla con i dati del back-end, dovresti creare un endpoint API REST e interrogarlo. Allora dove cade quel modello? E quando potremmo aver bisogno di GraphQL per entrare e risolverlo per noi?

Eve: Bene, il problema con cui GraphQL ci aiuta davvero, una specie di problema d'oro, la soluzione d'oro, immagino, che GraphQL fornisce è che con REST stiamo recuperando molti dati. Quindi, se ho utenti slash o prodotti slash, questo mi restituirà tutti i dati ogni volta che raggiungo il percorso.

Eve: Con GraphQL, possiamo essere un po' più esigenti sui dati che vogliamo. Quindi, se ho bisogno solo di quattro campi da un oggetto che ne ha cento, sarò in grado di individuare davvero quei campi e non dovrò caricare dati o caricare tutti quei dati, dovrei dire, nel tuo dispositivo, perché questo è un sacco di lavoro extra, soprattutto per il tuo telefono.

Drew: in passato ho visto e lavorato con API REST che hanno un campo facoltativo in cui è possibile passare un elenco dei dati che si desidera restituire, oppure è possibile aumentare ciò che viene restituito con cose extra. E quindi immagino che stia identificando questo problema, vero? Ciò vuol dire che non si desidera sempre che vengano restituiti gli stessi dati ogni volta. Quindi GraphQL formalizza quell'approccio di consentire al front-end di specificare cosa restituirà il back-end, in termini di dati?

Eve: Sì, esattamente. Quindi la tua domanda diventa quindi come chiedi, come filtri, come afferri qualsiasi tipo di informazione da qualsiasi luogo.

Eve: Penso anche che sia importante notare che non dobbiamo demolire tutte le nostre API REST per lavorare con GraphQL con successo. Molte delle implementazioni di maggior successo di GraphQL che ho visto là fuori, sono wrapper attorno alle API REST. E la query GraphQL ti dà davvero un modo per pensare a quali dati hai bisogno. E poi forse alcuni dei tuoi dati provengono dai nostri utenti e prodotti, esempi, alcuni dati provengono da REST, alcuni provengono da un database.

Drew: Immagino che lo scenario familiare sia che potresti avere un endpoint sul tuo sito Web che restituisce informazioni su un utente per visualizzare l'intestazione. Potrebbe darti il ​​loro nome utente e il loro avatar. E lo elimini su ogni pagina e popola i dati, ma poi trovi da qualche altra parte nella tua app che devi visualizzare il loro nome completo.

Drew: Quindi lo aggiungi all'endpoint e inizia a restituirlo. E poi fai la tua sezione di gestione dell'account e hai bisogno del loro indirizzo postale. In modo che venga restituito anche da quell'endpoint.

Drew: E prima che te ne accorga, quell'endpoint sta restituendo un intero carico utile pesante che costa parecchio sul back-end da mettere insieme e ovviamente molto da scaricare.

Drew: E questo è stato eliminato in ogni singola pagina solo per mostrare un avatar. Quindi immagino che sia il tipo di problema che cresce nel tempo, in cui è stato così facile cadere, in particolare nei grandi team, che GraphQL, è in cima a quel problema. Sa come risolverlo ed è progettato per risolverlo.

Eva: Esattamente. E sì, penso che l'intera idea di uno schema GraphQL, penso sia davvero meno discussa rispetto alla parte del linguaggio di query di GraphQL. Ma credo davvero che lo Schema in particolare ci dia questo bel sistema di tipi per API.

Eve: Quindi chiunque nel team, manager, sviluppatori front-end, sviluppatori back-end, chiunque abbia davvero a che fare con i dati può riunirsi, fondersi attorno a quali dati vogliamo effettivamente fornire su questa API, e quindi tutti sanno da quale fonte la verità è che possono costruire le proprie parti dell'app sulla base di quello.

Eve: Quindi ci sono alcune cose complicate di gestione dello schema che emergono anche da questo. Ma per quanto riguarda il passaggio dai microservizi ai monoliti, lo stiamo facendo, ma otteniamo comunque tutti i vantaggi che ci piacciono dai microservizi.

Drew: E ho capito bene che il modo tipico di impostare un sistema GraphQL è che avresti fondamentalmente un percorso, che è l'endpoint a cui invii tutte le tue query in modo da non dover... Spesso uno dei la cosa più difficile è capire come nominare e quale dovrebbe essere il percorso in cui dovrebbe trovarsi questa particolare query. Sta restituendo utenti e prodotti, dovrebbe essere tagliare qualcosa agli utenti o tagliare qualcosa al prodotto?

Drew: Con GraphQL hai solo un endpoint a cui invii le tue query e ottieni una risposta appropriata.

Eva: Esattamente. Sì. È un unico punto finale. Immagino che tu abbia ancora a che fare con problemi di denominazione perché stai nominando tutto nello Schema. Ma per quanto riguarda, mi sento come molte aziende che hanno fatto grandi scommesse sui microservizi, tutti sono tipo, quali endpoint abbiamo? Dove sono loro? Come sono documentati? E con GraphQL, abbiamo un posto, un tipo di dizionario per cercare tutto ciò che vogliamo scoprire su come funziona l'API.

Drew: Quindi, ho molta familiarità con altri linguaggi di query, ad esempio SQL è un ovvio esempio di linguaggio di query che molti sviluppatori web conosceranno. E le query in esso contenute assumono la forma quasi di un comando. È una stringa di testo, vero? Seleziona questo da quello, dove, qualunque cosa. Che formato hanno le query con GraphQL?

Eve: È ancora una stringa tecnologica, ma non definisce da dove viene quella logica. E gran parte della logica viene spostata sul server. Quindi il server GraphQL, l'API GraphQL è davvero responsabile di dire: "Vai a prendere questi dati da dove si trovano, filtrali in base a questi parametri".

Eve: Ma nel linguaggio delle query, è molto orientato al campo. Quindi aggiungiamo solo campi per tutto ciò che vogliamo recuperare. Possiamo anche mettere filtri su quelle query, ovviamente. Ma penso che sia un po' meno diretto da dove provengono queste informazioni. Molte delle funzionalità sono integrate nel server.

Drew: Quindi puoi combinare e abbinare in una query. È possibile effettuare una richiesta che riporti molti tipi di dati diversi in un'unica richiesta. È giusto?

Eve: Sì, è assolutamente vero. Quindi potresti inviare una query per tutti i campi consentiti dal tuo server e riportare tutti i tipi di dati nidificati. Ma è davvero così che funziona, colleghiamo diversi tipi sui campi. Quindi immagino che ricicleremo la mia idea di utenti e prodotti, ma l'utente potrebbe avere un campo prodotti che restituisce un elenco di prodotti. Tutti quelli sono associati anche con altri tipi. Quindi, per quanto profondamente nidificato vogliamo che la query vada, possiamo.

Drew: Quindi questo significa recuperare i dati per una vista tipica nella tua applicazione web che potrebbe avere ogni sorta di cose in corso, che puoi semplicemente fare una richiesta al back-end e ottenerlo tutto in una volta senza dover fare diversamente query a diversi endpoint, perché è tutto solo una cosa?

Eva: Sì. Questo è esattamente l'intero obiettivo, è solo una singola query, definire ogni campo desiderato e quindi restituirlo in una risposta.

Drew: E le query sono basate su JSON, giusto?

Eve: la query stessa è una stringa di testo, ma in genere restituisce dati JSON. Quindi, se ho i campi, la mia risposta JSON corrisponde esattamente, quindi è davvero chiaro cosa ottieni quando invii quella query, perché la risposta dei dati sembra esattamente la stessa.

Drew: Sembra che molte delle domande riguardino oggetti quasi spogli, come un cliente o un prodotto. C'è un modo per specificare query più complesse in cui la logica aziendale è controllata nel back-end? Supponiamo di voler ottenere un elenco di team per un utente, ma solo dove quell'utente è un amministratore di un team e dove il piano del team non è scaduto, e tutti quei tipi di vincoli reali che dobbiamo affrontare nello sviluppo di applicazioni Web di tutti i giorni. È possibile ottenerlo con GraphQL?

Eva: Assolutamente. Quindi questa è la vera cosa eccitante e potente di GraphQL è che puoi spostare molta di quella logica sul server. Se avessi una query complessa, un tipo di utente davvero specifico che volevi ottenere, tutto ciò che dovresti fare nello schema è dire "Ottieni utente complicato" e quindi sul server ci sarebbe una funzione in cui potresti scrivere tutta la logica in qualsiasi lingua tu voglia. JavaScript è una specie del linguaggio di implementazione GraphQL più popolare, ma non è necessario utilizzarlo affatto. Quindi Python, Go, C++, qualunque cosa tu voglia usare, puoi creare un server GraphQL con quello. Ma sì, puoi definire una query complessa come desideri.

Drew: E immagino che ciò ti permetta di incapsulare molta logica aziendale in nuovi tipi di oggetti. È giusto? Sai, hai impostato un utente complicato e quindi non hai bisogno di pensare cosa sia un utente complicato, ma puoi semplicemente continuare a usare quell'utente complicato e sapere che la logica aziendale è implementata su quello. È giusto?

Eve: È proprio così. Quindi penso che questo sia davvero bello per le persone del front-end perché possono iniziare a creare prototipi sulla base di quello. E poi il team di back-end potrebbe implementare quelle funzioni per farlo funzionare. E poi c'è una sorta di comprensione condivisa di cosa sia effettivamente quel tipo e chi sono, e "Quali sono i campi su quel tipo?" E tutto può essere gestito ovunque nello stack GraphQL stia funzionando. Ed è per questo che non è realmente una tecnologia front-end o back-end. È davvero una specie di entrambi, e nessuno dei due.

Drew: Sembra che sia una sorta di formalizzazione dell'API e della relazione tra front-end e back-end, quindi tutti ottengono un'interfaccia prevedibile e standardizzata.

Eva: Esattamente.

Drew: Ciò che immagino nelle organizzazioni in cui il front-end e il back-end sono di proprietà di team diversi, il che non è affatto raro, immagino che questo approccio consenta anche di apportare modifiche, ad esempio, sul front-end, potrebbe richiedere dati, senza bisogno di qualcuno che lavori sul back-end per apportare le modifiche corrispondenti. Hai ancora questa API quasi infinitamente personalizzabile senza richiedere alcun lavoro per cambiarla se hai bisogno di nuovi dati.

Eve: Sì, esatto.

Drew: Quindi il server GraphQL è responsabile della formattazione della risposta o è necessario farlo nella logica lato server?

Eve: Quindi il server GraphQL definisce due cose. Definisce lo schema stesso che risiede sul server, quindi definisce le funzioni del risolutore. Queste sono funzioni che ottengono i dati ovunque si trovino. Quindi, se ho un'API REST che sto avvolgendo con GraphQL, il risolutore prenderebbe da quell'API, trasformerebbe i dati come doveva essere e quindi li restituirebbe al client in quella funzione. Puoi utilizzare qualsiasi tipo di funzione di database che desideri anche su quel server. Quindi, se hai dati in un sacco di posti diversi, questo è davvero un bel posto coeso in cui inserire tutti quei dati e in qualche modo progettare tutta la logica attorno, "Da dove arrivano quei dati? Come vogliamo trasformarlo?”

Drew: Il client dice "Voglio un utente complesso", il server lo riceve in una query e potrebbe dire: "Va bene, cercherò il risolutore utente complesso". È giusto?

Eve: Mm-hmm (affermativo).

Drew: Qual è la funzione, e poi scrivi la tua logica che il tuo team di back-end, o chiunque scriva la logica all'interno di quella funzione, per fare tutto ciò che è necessario per restituire un utente complesso.

Eve: Sì, esattamente.

Drew: Quindi potrebbe essere chiamare altre API, potrebbe essere una query su un database, potrebbe cercare cose nella cache o praticamente qualsiasi cosa.

Eve: Praticamente qualsiasi cosa. E quindi, finché quel ritorno dalla funzione corrisponde ai requisiti dello Schema, corrisponde a quali campi, quali tipi, stavano tornando lì, allora tutto funzionerà bene e armoniosamente.

Drew: Immagino che ti dia un formato di risposta coerente nell'intera API solo per impostazione predefinita. Non devi progettare come appare. Ottieni solo un risultato coerente.

Eve: Sì, esattamente.

Drew: Penso che potrebbe essere davvero una bella vittoria, perché può essere davvero difficile mantenere la coerenza su una vasta gamma di punti finali API, specialmente nei team più grandi. Persone diverse stanno lavorando su cose diverse. A meno che tu non disponga di una governance piuttosto rigida, può diventare molto complesso molto rapidamente, vero?

Eve: Sì, assolutamente. E penso che Schema sia solo un bel piccolo documento per descrivere tutto. Ottieni il vantaggio automatico di poter vedere tutti i campi in quello schema ogni volta che provi a inviargli query, perché puoi inviare query di introspezione e ci sono tutti i tipi di strumenti utili per questo, come GraphQL e GraphQL Playground, piccoli strumenti che puoi utilizzare per interagire con i dati dell'API.

Eve: Ma anche, se hai mai giocato con Postman, ti piace fare il ping di un'API REST, molti di quelli, la documentazione non esiste davvero o è difficile da trovare, o cose del genere. GraphQL ti offre davvero quel bel livello coeso per descrivere tutto ciò che potrebbe far parte di quell'API.

Drew: In pratica, come funzionano le cose sul lato server? Voglio dire, immagino che tu debba eseguire un servizio GraphQL come parte della tua infrastruttura, ma che forma prende? È un intero server in esecuzione sulla propria porta? O è proprio come una libreria che integri nel tuo Express o Apache esistente o qualsiasi altra cosa con un percorso che risolve quel servizio? Come lo implementi?

Eve: Sì, è un vero server. Quindi una delle implementazioni GraphQL più popolari sono i server Node.js. Quando GraphQL è stato rilasciato come specifica, il team ha rilasciato questa implementazione di riferimento in JavaScript, una specie di server Node che fungeva da linee guida per tutti questi altri che sono spuntati. Ma sì, puoi eseguire questi server sulle proprie istanze. Puoi metterli su Lambda. Quindi c'è Apollo Server Express, c'è Apollo Server Lambda; tutti i tipi di diversi tipi di implementazioni che puoi usare per eseguire effettivamente questa cosa.

Drew: Quindi hai menzionato brevemente prima il concetto di Schema che ha il server.

Eva: Sì.

Drew: Questo ti dà la possibilità di descrivere i tuoi tipi in modo più rigoroso del semplice, sai, mappare un nome su un risolutore. C'è di più coinvolto lì, vero?

Eva: Sì. C'è una lingua completa. Quindi ho fatto riferimento alle specifiche e non ho descritto di cosa si tratta. GraphQL stesso è una specifica che descrive il linguaggio di query e il linguaggio di definizione dello schema. Quindi ha una sua sintassi. Ha le sue regole per definire questi tipi.

Eve: Quando usi il linguaggio di definizione dello schema, fondamentalmente usi tutte le funzionalità di quel linguaggio per pensare, quali sono i tipi che fanno parte dell'API? È anche il punto in cui definisci le query, le mutazioni, che sono i verbi, come le azioni, crea l'accesso all'account, cose del genere. E anche gli abbonamenti GraphQL, che sono un'altra cosa interessante, GraphQL in tempo reale che puoi definire proprio lì nello Schema.

Eve: Quindi sì, lo Schema è davvero molto importante. E penso che ci dia questa bella applicazione del tipo in tutta la nostra applicazione Stack completa, perché non appena inizi a deviare da quei campi e da quei tipi, inizi a vedere errori, il che è, in tal caso, positivo, perché tu stai seguendo le regole dello Schema.

Drew: C'è qualche incrocio tra quello e TypeScript? C'è una sorta di sinergia tra i due?

Eva: Assolutamente. Quindi, se sei una persona che parla molto di GraphQL, a volte le persone ti diranno che non va bene, e verranno da te pubblicamente, quando potresti farlo, e parleranno di come GraphQL non va bene. Ma molte volte saltano fuori le cose interessanti che ottieni dai tipi. Quindi, per quanto riguarda la sinergia con TypeScript, assolutamente, puoi generare automaticamente tipi per la tua applicazione front-end usando i tipi dallo Schema. Quindi è un'enorme vittoria perché non solo puoi generarlo la prima volta, il che ti offre una grande interoperabilità con la tua applicazione front-end, ma anche, man mano che le cose cambiano, puoi rigenerare i tipi e quindi creare per riflettere tali modifiche. Quindi sì, penso che queste cose si adattino molto bene insieme poiché i tipi iniziano a essere una specie di regola de facto.

Eve: ... per essere una specie di regola de facto in JavaScript, si adattano bene insieme.

Drew: Sembra essere una sorta di tema in corso con il modo in cui TypeScript è stato progettato … non è TypeScript, mi dispiace. GraphQL è stato progettato per formalizzare molto l'interazione tra il front-end e il back-end. E sta arrivando come una soluzione tra la giusta coerenza e la formalizzazione di quella che finora è stata un'esperienza piuttosto frammentaria con riposo per molte persone. Una cosa che dobbiamo sempre tenere a mente quando scriviamo app lato client è che il codice è soggetto a ispezione e potenzialmente a modifiche. E avere un'API in cui il client può semplicemente richiedere dati potrebbe essere pericoloso. Ora, se puoi specificare quali campi vuoi, forse potrebbe essere pericoloso. In quale parte dell'intero stack, ti ​​occuperai dell'autorizzazione degli utenti e ti assicureresti che le regole aziendali relative ai tuoi dati vengano applicate?

Eve: Ti occuperai di tutto questo sul server. Quindi, ciò potrebbe accadere in molti modi diversi. Non è necessario utilizzare una strategia una tantum, ma i tuoi risolutori gestiranno la tua autorizzazione. Quindi ciò potrebbe significare avvolgere un'API REST esistente, come un servizio come Auth0 o qualcosa che hai creato da solo. Ciò potrebbe significare interagire con un OAuth, come GitHub o Facebook o l'accesso a Google, quel tipo di cose che implicano il passaggio di token avanti e indietro con i resolver. Ma spesso questo sarà integrato direttamente nello Schema. Quindi lo schema dirà, non lo so, creeremo una mutazione di accesso. E poi invio quella mutazione con le mie credenziali e poi sul server, tutte quelle credenziali vengono verificate. Quindi il cliente non deve preoccuparsi così tanto, forse un po' di passaggio di token e cose del genere. Ma la maggior parte di questo è solo integrato nel server.

Drew: Quindi, in sostanza, questo non cambia davvero rispetto al modo in cui stiamo costruendo gli endpoint di riposo al momento. Resto come una tecnologia, beh, non si occupa nemmeno dell'autorizzazione e abbiamo middleware e cose sul server che si occupano di esso. Ed è lo stesso con GraphQL. Devi solo affrontarlo. Ci sono convenzioni nella comunità di GraphQL per farlo? Esistono approcci comuni o è ovunque il modo in cui le persone scelgono di implementarlo?

Eve: Onestamente è dappertutto. Penso che la maggior parte delle volte vedrai persone che si integrano nello Schema e con questo intendo che rappresentano quei tipi e utenti autorizzati rispetto agli utenti normali che costruiscono quei tipi nello Schema stesso. Ma vedrai anche molte persone che usano soluzioni di terze parti. Ho citato Auth0. Molte persone scaricano la loro autorizzazione su società che sono più concentrate su di essa, in particolare società più piccole, startup, cose del genere. Ma vedrai anche aziende più grandi iniziare a creare soluzioni per questo. Quindi AWS, Amazon ha AppSync, che è la loro versione di GraphQL, e hanno i ruoli degli autori integrati direttamente in AppSync. Ed è bello solo essere in grado, non so, di non doversi preoccupare di tutte quelle cose o almeno di fornire un'interfaccia per lavorarci. Quindi molti di questi strumenti dell'ecosistema hanno, penso che l'autorizzazione sia un argomento così importante in GraphQL. Hanno visto il tipo di necessità, la richiesta di soluzioni di autenticazione e approcci standard alla gestione dell'autenticazione sul grafico.

Drew: Immagino che non ci sia quasi un'implementazione là fuori che non abbia bisogno di una sorta di autorizzazione. Quindi sì, sarà un requisito abbastanza comune. Stiamo creando sempre più applicazioni componenti, in particolare quando utilizziamo le cose React and View e quello che hai. E il principio dell'accoppiamento libero ci lascia con molti componenti che non sanno necessariamente cos'altro scorre nella pagina che li circonda. C'è il pericolo di conseguenza, potresti ritrovarti con molti componenti che eseguono query per gli stessi dati e fanno più richieste? O è solo un problema architettonico nella tua app che devi risolvere per quello? Ci sono soluzioni ben note per affrontarlo?

Eve: Beh, penso perché GraphQL per la maggior parte, non il 100% delle soluzioni, ma quasi tutte le query GraphQL vengono inviate tramite HTTP. Quindi, se vuoi rintracciare dove si verificano queste richieste multiple, è probabilmente un problema abbastanza familiare per le persone che utilizzano i dati di riposo per le loro applicazioni. Quindi ci sono alcuni strumenti come Paulo Client Dev Tools e Urkel Dev Tools per sviluppatori front-end che dicono: "Cosa sta succedendo? Quali domande ci sono in questa pagina?" Questo ti dà una visione davvero chiara di ciò che sta accadendo. Ci sono una specie di diverse scuole di pensiero con questo. Creiamo una query grande, enorme per tutti i dati per la pagina? Oppure creiamo query più piccole per caricare i dati per diverse parti dell'app? Entrambi, come puoi immaginare, hanno i loro svantaggi, solo perché se hai una query grande, stai aspettando più campi.

Eve: se hai query più piccole, potrebbero esserci delle collisioni tra i dati che stai richiedendo. Ma penso, e non per andare troppo per la tangente, ma ci sono già. Quindi c'è qualcosa chiamato Direttiva Deferred che sta arrivando alle specifiche GraphQL e la Direttiva Deferred aiuterà con una sorta di caricamento secondario dei contenuti. Quindi supponiamo che tu abbia dei contenuti nella parte superiore della pagina, i contenuti super importanti che vuoi caricare per primi. Se lo aggiungi alla tua query e quindi tutti i campi successivi ottengono la direttiva differita su quello. È solo un piccolo decoratore che aggiungeresti a un campo, che poi dirà: "Va bene, carica prima i dati importanti, quindi tieni premuto e carica i secondi secondi". E in qualche modo ti dà questo, è l'aspetto di una sorta di streaming di dati sul tuo front-end, in modo che ci siano prestazioni percepite, c'è interattività. Le persone vedono i dati immediatamente invece di aspettare che ogni singolo campo venga caricato per la pagina, il che sì, potrebbe essere un problema.

Drew: Sì. Immagino che ciò ti permetta di progettare pagine in cui tutto ciò che è... non ci piace parlare troppo del viewport, ma è tutto above the fold, potresti dare la priorità, caricare quel carico e poi caricare secondariamente qualsiasi altro fuori uso. Quindi, abbiamo parlato molto dell'interrogazione dei dati. Uno dei compiti principali di un'API è l'invio di dati nuovi e modificati al server per la persistenza. Prima hai menzionato brevemente le mutazioni. Questa è la terminologia utilizzata da GraphQL per riscrivere i dati sul server?

Eva: Esattamente. Quindi qualsiasi tipo di modifica che vogliamo apportare ai dati, tutto ciò che vogliamo riscrivere sul server, quelle sono mutazioni e sono tutte proprio come query, sono operazioni denominate che risiedono sul server. Quindi puoi pensare a quali sono tutte le cose che vogliamo che i nostri utenti siano in grado di fare? Rappresenta quelli con mutazioni. E poi di nuovo sul server, scrivi tutte le funzioni che fanno funzionare quella roba.

Drew: Ed è semplice come eseguire una query per i dati? Chiamare una mutazione è altrettanto facile?

Eva: Sì. Fa parte del linguaggio di query. Sembra praticamente identico. L'unica differenza è, beh, suppongo che le query prendano filtri. Quindi le mutazioni hanno preso quelli che sembravano filtri nella query stessa. Ma quelli sono responsabili dell'effettiva modifica dei dati. Un'e-mail e una password potrebbero essere inviate con una mutazione, quindi il server la raccoglie e quindi la utilizza per autorizzare l'utente.

Drew: Quindi, proprio come prima, stai creando un risolutore sul back-end per affrontarlo e per fare tutto ciò che deve essere fatto. Un'occorrenza comune durante la scrittura dei dati è che si desidera eseguire il commit delle modifiche e quindi eseguire nuovamente la query per ottenere il tipo di stato corrente di essi. GraphQL ha un buon flusso di lavoro per questo?

Eve: In un certo senso vive nella mutazione stessa. Quindi, molte volte durante la creazione del tuo schema creerai l'operazione di mutazione. Rimarrò con il login, prenderò l'e-mail e la password. E la mutazione stessa ha restituito qualcosa. Quindi potrebbe restituire qualcosa di semplice come un booleano, questo è andato bene, o questo è andato male, oppure potrebbe restituire un tipo reale. Così spesso vedrai la mutazione come la mutazione di accesso, forse restituisce un utente. Quindi ottieni tutte le informazioni sull'utente una volta che ha effettuato l'accesso. Oppure puoi creare un tipo di oggetto personalizzato che ti dia quell'utente più l'ora in cui l'utente ha effettuato l'accesso e forse un po' più di metadati su quella transazione nell'oggetto restituito . Quindi, di nuovo, sta a te progettarlo, ma quel modello è davvero integrato in GraphQL.

Drew: Tutto questo suona abbastanza bene, ma ogni scelta tecnica comporta dei compromessi. Quali sono gli svantaggi dell'utilizzo di GraphQL? Ci sono scenari in cui sarebbe una scelta davvero sbagliata?

Eve: Penso che il punto in cui un GraphQL potrebbe avere difficoltà sia la creazione di una mappa uno-a-uno di-

Eve: … la lotta è creare una mappa uno-a-uno di dati tabulari. Quindi diciamo che hai, non lo so, pensato a una tabella di database con tutti i tipi di campi diversi e, non lo so, migliaia di campi su un tipo specifico, cose del genere, quel tipo di dati può essere rappresentato bene con GraphQL, ma a volte quando esegui un processo per generare uno schema su quei dati, ti rimangono, in uno schema, gli stessi problemi che avevi nel database, che forse sono troppi dati che vanno oltre quelli del client effettivamente richiede. Quindi penso che quei posti siano potenzialmente problemi. Ho parlato con persone che hanno generato automaticamente schemi in base ai loro dati ed è diventato uno schema lungo un milione di righe o qualcosa del genere, solo migliaia e migliaia di righe di codice dello schema. Ed è qui che diventa un po 'complicato, ad esempio quanto è utile questo come documento leggibile dall'uomo?

Eva: Sì. Quindi, qualsiasi tipo di situazione in cui hai a che fare con un cliente, è davvero una buona soluzione per quanto riguarda la modellazione di ogni diverso tipo di dati, diventa un po' complicato se le tue origini dati sono troppo grandi.

Drew: Quindi sembra che ovunque tu curerai attentamente le risposte nei campi e lo farai di più a mano, puoi ottenere risultati davvero potenti. Ma se stai generando automaticamente roba perché hai solo uno schema enorme, allora forse diventa un po' ingombrante.

Eva: Sì. E penso che le persone mi ascoltino e non siano d'accordo con me su questo perché ci sono buoni strumenti anche per questo. Ma penso che il punto in cui GraphQL brilla davvero sia quel passaggio di astrazione della logica al server, dando agli sviluppatori front-end la libertà di definire i loro componenti o i loro requisiti di dati front-end e gestendo davvero lo Schema come una squadra.

Drew: C'è qualcosa di integrato nel linguaggio di query per gestire l'impaginazione dei risultati o si tratta di un'implementazione personalizzata secondo necessità?

Eva: Sì. Impaginazione, costruiresti prima nello Schema, quindi potresti definire l'impaginazione per quello. Ci sono molte linee guida che sono emerse nella comunità. Un buon esempio da guardare se sei un nuovo utente di GraphQL o meno, lo guardo sempre, è l'API GitHub GraphQL. Fondamentalmente hanno ricreato la loro API per la v4 della loro API pubblica utilizzando GraphQL. Quindi questo è un buon punto per guardare in che modo una vera grande azienda lo utilizza su larga scala. Molte persone hanno grandi API in esecuzione, ma non le rendono pubbliche a tutti. Quindi l'impaginazione è incorporata in quell'API davvero bene e puoi restituire, non lo so, i primi 50 repository che tu abbia mai creato, oppure puoi anche utilizzare l'impaginazione basata sul cursore per restituire record in base alle idee nei tuoi dati. Quindi l'impaginazione basata sul cursore e il tipo di impaginazione posizionale come il primo, l'ultimo record, di solito è così che le persone si avvicinano a questo, ma ci sono molte tecniche.

Drew: Ci sono dei grossi problemi che dovremmo sapere sull'uso di GraphQL? Supponiamo che stia per distribuire una nuova installazione di GraphQL per la mia organizzazione, creeremo tutti i nostri nuovi endpoint API utilizzando GraphQL in futuro. Cosa dovrei sapere? C'è qualcosa in agguato tra i cespugli?

Eve: In agguato tra i cespugli, sempre con la tecnologia, giusto? Penso che una delle cose che non è integrata in GraphQL, ma può essere implementata senza troppi problemi, sia la sicurezza delle API. Quindi, ad esempio, hai menzionato che se ho una query enorme, ne abbiamo parlato con l'autorizzazione, ma è anche spaventoso aprire un'API in cui qualcuno potrebbe semplicemente inviare una query nidificata enorme, amici di amici, amici di amici, amici di amici , giù e giù per la catena. E poi stai praticamente permettendo alle persone di DDoS con queste enormi query. 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. Assolutamente.

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. Hai qualche parola d'addio?

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