Smashing Podcast Folge 31 mit Eve Porcello: Was ist GraphQL?
Veröffentlicht: 2022-03-10In dieser Folge sprechen wir über GraphQL. Was ist das und wie werden einige allgemeine API-Probleme gelöst? Ich habe mit der Expertin Eve Porcello gesprochen, um das herauszufinden.
Notizen anzeigen
- Eva auf Twitter
- Eves Firma Moon Highway
- GraphQL von O'Reilly lernen
- Discover Your Path Through The GraphQL Wilderness – Eves GraphQL-Workshop startet Anfang 2021
Wöchentliches Update
- Verwendung von in Sanity gespeichertem MDX auf einer Next.js-Website
Geschrieben von Jason Lengstorf - Aufbau eines Conversational NLP-fähigen Chatbots mit Googles Dialogflow
geschrieben von Nwani Victory - Ethische Überlegungen in der UX-Forschung: Die Notwendigkeit von Training und Überprüfung
Geschrieben von Victor Yocco - Webseiten leichter verständlich machen
Geschrieben von Frederick O'Brien - So entwerfen Sie eine einfache Benutzeroberfläche, wenn Sie eine komplexe Lösung haben
Geschrieben von Suzanne Scacca
Abschrift
Drew McLellan: Sie ist Software-Ingenieurin, Ausbilderin, Autorin und Mitbegründerin des Schulungs- und Lehrplanentwicklungsunternehmens Moon Highway. Ihre Karriere begann mit dem Schreiben technischer Spezifikationen und dem Erstellen von UX-Designs für Webprojekte. Seit sie Moon Highway im Jahr 2012 gegründet hat, hat sie Videoinhalte für egghead.io und LinkedIn Learning erstellt und ist Co-Autorin der Bücher Learning React und Learning GraphQL für O'Reilly's Media.
Drew: Sie ist auch eine häufige Rednerin auf Konferenzen und hat auf Konferenzen wie React Rally, GraphQL Summit und OSCON Vorträge gehalten. Wir wissen also, dass sie eine Expertin für GraphQL ist, aber wussten Sie, dass sie einmal einem Eisbären das Schachspielen beigebracht hat? Meine großartigen Freunde, bitte heißt Eve Porcello willkommen.
Drew: Hallo Eva, wie geht es dir?
Eve Porcello: Ich bin umwerfend.
Drew: Wie ich dort erwähnt habe, sind Sie in Sachen JavaScript und React sehr viel Ausbilder, aber ich wollte heute mit Ihnen über eines Ihrer anderen Spezialgebiete sprechen, GraphQL. Viele von uns werden in gewisser Weise von GraphQL gehört haben, sind sich aber möglicherweise nicht ganz sicher, was es ist oder was es tut und insbesondere welche Art von Problem es im Webstack löst.
Drew: Bereiten Sie also die Bühne für uns vor, wenn Sie so wollen, wenn ich ein Frontend-Entwickler bin, wo fügt sich GraphQL in das Ökosystem ein und welche Funktion erfüllt es für mich?
Eva: Ja. GraphQL passt irgendwie zwischen das Frontend und das Backend. Es lebt irgendwie in der Mitte zwischen den beiden und bietet Front-End-Entwicklern und Back-End-Entwicklern viele Vorteile.
Eve: Wenn Sie ein Front-End-Entwickler sind, können Sie alle Ihre Front-End-Datenanforderungen definieren. Wenn Sie also beispielsweise eine große Liste von React-Komponenten haben, können Sie eine Abfrage schreiben. Und das wird alle Felder definieren, die Sie benötigen würden, um die Daten für diese Seite auszufüllen.
Eve: Jetzt mit dem Backend-Stück ist es wirklich eigen, weil wir viele Daten aus vielen verschiedenen Quellen sammeln können. Wir haben also Daten in REST-APIs und Datenbanken und all diesen verschiedenen Orten. Und GraphQL bietet uns diese nette kleine Orchestrierungsebene, um das Chaos, in dem sich all unsere Daten befinden, wirklich zu verstehen. Es ist also wirklich nützlich für so ziemlich jeden auf dem ganzen Stack.
Drew: Es ist also im Grunde eine API-basierte Technologie, nicht wahr? Es sitzt zwischen Ihrem Frontend und Ihrem Backend und stellt eine Art API bereit, ist das richtig?
Eve: Ja, das ist genau richtig. Exakt.
Drew: Ich denke, in den letzten zehn Jahren war Ruhe der Goldstandard für APIs. Wenn Sie also eine clientseitige Anwendung haben und diese mit Daten aus dem Backend füllen müssen, würden Sie einen REST-API-Endpunkt erstellen und diesen abfragen. Also, wo fällt dieses Modell hin? Und wann brauchen wir vielleicht GraphQL, um das für uns zu lösen?
Eve: Nun, das Problem, bei dem uns GraphQL wirklich hilft, eine Art goldenes Problem, die goldene Lösung, die GraphQL bietet, ist, dass wir mit REST zu viele Daten abrufen. Wenn ich also Slash-Benutzer oder Slash-Produkte habe, werden mir jedes Mal, wenn ich auf Route gehe, alle Daten zurückgegeben.
Eve: Mit GraphQL können wir etwas wählerischer sein, welche Daten wir wollen. Wenn ich also nur vier Felder von einem Objekt benötige, das hundert hat, kann ich diese Felder wirklich lokalisieren und muss keine Daten in Ihr Gerät laden, oder ich sollte sagen, alle diese Daten in Ihr Gerät laden, weil Das ist eine Menge zusätzlicher Laufarbeit, besonders für Ihr Telefon.
Drew: Ich habe in der Vergangenheit REST-APIs gesehen und damit gearbeitet, die ein optionales Feld haben, in dem Sie eine Liste der Daten übergeben können, die Sie zurückgeben möchten, oder Sie können das, was zurückkommt, mit zusätzlichen Dingen erweitern. Und ich denke, das identifiziert dieses Problem, nicht wahr? Das heißt, Sie möchten nicht jedes Mal dieselben Daten zurückhaben. Ist es also so, dass GraphQL diesen Ansatz formalisiert, dem Frontend zu erlauben, anzugeben, was das Backend in Bezug auf Daten zurückgeben wird?
Eva: Ja, genau. Ihre Abfrage wird also zu Ihrer Frage, wie Sie filtern, wie Sie von überall nach Informationen suchen.
Eve: Ich denke auch, dass es wichtig ist, darauf hinzuweisen, dass wir nicht alle unsere REST-APIs herunterreißen müssen, um wirklich erfolgreich mit GraphQL zu arbeiten. Viele der erfolgreichsten Implementierungen von GraphQL, die ich gesehen habe, sind Wrapper um REST-APIs. Und die GraphQL-Abfrage gibt Ihnen wirklich die Möglichkeit, darüber nachzudenken, welche Daten Sie benötigen. Und dann stammen vielleicht einige Ihrer Daten von unseren Benutzern und Produkten, Beispiele, einige der Daten stammen aus REST, andere stammen aus einer Datenbank.
Drew: Ich denke, das bekannte Szenario ist, dass Sie möglicherweise einen Endpunkt auf Ihrer Website haben, der Informationen über einen Benutzer zurückgibt, um den Header anzuzeigen. Es könnte Ihnen ihren Benutzernamen und ihren Avatar geben. Und Sie sammeln das auf jeder Seite und füllen die Daten aus, aber dann finden Sie irgendwo in Ihrer App, wo Sie ihren vollständigen Namen anzeigen müssen.
Drew: Sie fügen das also dem Endpunkt hinzu und es beginnt damit, es zurückzugeben. Und dann machen Sie Ihren Account-Management-Bereich, und Sie brauchen wie ihre Postanschrift. Das wird also auch von diesem Endpunkt zurückgegeben.
Drew: Und ehe man sich versieht, gibt dieser Endpunkt eine ganze Menge Nutzlast zurück, deren Zusammenstellung im Backend ziemlich viel kostet, und natürlich viel zum Herunterladen.
Drew: Und das wurde auf jeder einzelnen Seite ausgesondert, nur um einen Avatar zu zeigen. Ich denke, das ist die Art von Problem, das mit der Zeit wächst, in das man besonders in großen Teams so leicht geraten kann, dass GraphQL dieses Problem überlagert. Es weiß, wie man das löst, und es ist darauf ausgelegt, das zu lösen.
Eva: Genau. Und ja, ich denke, über diese ganze Idee eines GraphQL-Schemas wird wirklich weniger gesprochen als über den Teil der Abfragesprache von GraphQL. Aber ich habe wirklich das Gefühl, dass uns insbesondere das Schema dieses nette Typsystem für die API gibt.
Eve: Jeder im Team, Manager, Front-End-Entwickler, Back-End-Entwickler, jeder, der wirklich mit Daten zu tun hat, kann zusammenkommen und sich darüber zusammenschließen, welche Daten wir tatsächlich auf dieser API bereitstellen möchten, und dann weiß jeder, aus welcher Quelle In Wahrheit können sie darauf basierend ihre eigenen Teile der App erstellen.
Eve: Es gibt also auch einige knifflige Schema-Verwaltungsdinge, die damit einhergehen. Aber was den Übergang von Microservices zurück zu Monolithen angeht, tun wir das in gewisser Weise, erhalten aber immer noch alle Vorteile, die wir von Microservices erwarten.
Drew: Und habe ich das richtig verstanden, dass die typische Art und Weise, ein GraphQL-System einzurichten, darin besteht, dass Sie im Grunde genommen eine Route haben, das ist der Endpunkt, an den Sie alle Ihre Abfragen senden, damit Sie nicht müssen ... Oft einer der Am schwierigsten ist es herauszufinden, was zu benennen ist und wie der Pfad aussehen sollte, an dem diese spezielle Abfrage erfolgen sollte. Es handelt sich um wiederkehrende Benutzer und Produkte, sollte es etwas Schrägstrich für Benutzer oder etwas Schrägstrich für Produkt sein?
Drew: Mit GraphQL haben Sie nur einen Endpunkt, an den Sie Ihre Abfragen senden, und Sie erhalten eine entsprechende Antwort.
Eva: Genau. Ja. Es ist ein einzelner Endpunkt. Ich schätze, Sie haben immer noch Probleme mit der Benennung, weil Sie alles im Schema benennen. Aber soweit es mir wie viele Unternehmen geht, die große Wetten auf Microservices abgeschlossen haben, fragen sich alle: Welche Endpunkte haben wir? Wo sind sie? Wie werden sie dokumentiert? Und mit GraphQL haben wir einen Ort, eine Art Wörterbuch, um alles nachzuschlagen, was wir über die Funktionsweise der API herausfinden möchten.
Drew: Also, ich bin sehr vertraut mit anderen Abfragesprachen, wie SQL ist ein offensichtliches Beispiel für eine Abfragesprache, die viele Webentwickler kennen werden. Und die Abfragen darin haben fast die Form eines Befehls. Es ist eine Textzeichenfolge, nicht wahr, Wählen Sie dies aus dem, wo, was auch immer. Welches Format nehmen die Abfragen mit GraphQL an?
Eve: Es ist immer noch ein Tech-String, aber es definiert nicht, woher diese Logik kommt. Und ein Großteil der Logik wird zurück auf den Server verlagert. Der GraphQL-Server, die GraphQL-API, ist also wirklich dafür verantwortlich zu sagen: „Holen Sie sich diese Daten von dort, wo sie sind, filtern Sie sie basierend auf diesen Parametern.“
Eve: Aber die Abfragesprache ist sehr feldorientiert. Also fügen wir einfach Felder für alles hinzu, was wir abrufen möchten. Natürlich können wir diese Abfragen auch filtern. Aber ich denke, es ist etwas weniger direkt, woher diese Informationen stammen. Ein Großteil der Funktionalität ist in den Server integriert.
Drew: So können Sie in einer Abfrage mischen und abgleichen. Sie können eine Anfrage stellen, die viele verschiedene Datentypen in einer Anfrage zurückbringt. Ist das richtig?
Eve: Ja, das ist absolut richtig. Sie könnten also eine Abfrage für so viele Felder senden, wie Ihr Server zulässt, und alle möglichen verschachtelten Daten zurückgeben. Aber so funktioniert es wirklich, wir verbinden verschiedene Typen auf Feldern. Ich denke, wir werden meine Benutzer- und Produktidee recyceln, aber der Benutzer hat möglicherweise ein Produktfeld, das eine Liste von Produkten zurückgibt. Alle diese sind auch mit anderen Typen verbunden. Wir können also so tief verschachtelt, wie wir die Abfrage haben wollen.
Drew: Bedeutet das also, die Daten für eine typische Ansicht in Ihrer Webanwendung abzurufen, in der möglicherweise alle möglichen Dinge vor sich gehen, dass Sie nur eine Anfrage an das Backend stellen und alles auf einmal abrufen können, ohne etwas ändern zu müssen Abfragen an verschiedene Endpunkte, weil es nur eine Sache ist?
Eva: Ja. Das ist genau das ganze Ziel, ist nur eine einzige Abfrage, definieren Sie jedes gewünschte Feld und geben Sie es dann in einer Antwort zurück.
Drew: Und die Abfragen basieren auf JSON, stimmt das?
Eve: Die Abfrage selbst ist eine Textzeichenfolge, aber sie gibt normalerweise JSON-Daten zurück. Wenn ich also die Felder habe, stimmt meine JSON-Antwort genau überein, und es ist wirklich klar, was Sie erhalten, wenn Sie diese Abfrage senden, da die Datenantwort genau gleich aussieht.
Drew: Viele der Abfragen scheinen fast wie bloße Objekte zu sein, wie ein Kunde oder ein Produkt. Gibt es eine Möglichkeit, komplexere Abfragen anzugeben, bei denen die Geschäftslogik am Backend gesteuert wird? Angenommen, ich möchte eine Liste der Teams für einen Benutzer abrufen, aber nur, wenn dieser Benutzer ein Administrator eines Teams ist und der Teamplan nicht abgelaufen ist, und all diese Arten von echten Einschränkungen, mit denen wir bei der täglichen Entwicklung von Webanwendungen konfrontiert sind. Kann das mit GraphQL erreicht werden?
Eva: Absolut. Das wirklich Aufregende und Leistungsstarke an GraphQL ist also, dass Sie einen Großteil dieser Logik auf den Server verschieben können. Wenn Sie eine komplexe Abfrage hätten, einen wirklich bestimmten Benutzertyp, den Sie erhalten möchten, müssten Sie im Schema nur sagen: „Komplizierten Benutzer abrufen“, und dann gäbe es auf dem Server eine Funktion wo Sie könnten die gesamte Logik in jeder gewünschten Sprache schreiben. JavaScript ist sozusagen die beliebteste GraphQL-Implementierungssprache, aber Sie müssen das überhaupt nicht verwenden. Also Python, Go, C++, was auch immer Sie verwenden möchten, Sie können damit einen GraphQL-Server erstellen. Aber ja, Sie können eine Abfrage so komplex definieren, wie Sie möchten.
Drew: Und ich denke, das ermöglicht es Ihnen, eine Menge Geschäftslogik dann in neue Arten von Objekten einzukapseln. Ist das fair? Wissen Sie, Sie richten einen komplizierten Benutzer ein und müssen dann nicht darüber nachdenken, was ein komplizierter Benutzer ist, aber Sie können diesen komplizierten Benutzer einfach weiter verwenden und wissen, dass die Geschäftslogik darauf implementiert ist. Ist das richtig?
Eva: Das ist genau richtig. Also ich denke, das ist wirklich nett für Front-End-Leute, weil sie damit anfangen können, Prototypen zu entwickeln. Und dann könnte das Backend-Team diese Funktionen implementieren, damit das funktioniert. Und dann gibt es eine Art gemeinsames Verständnis dafür, was dieser Typ eigentlich ist und wer er ist, und: „Was sind die Felder dieses Typs?“ Und alles kann von überall im Stack gehandhabt werden, wo GraphQL arbeitet. Und deshalb ist es nicht wirklich eine Front-End- oder Back-End-Technologie. Es ist wirklich irgendwie beides und keins von beidem.
Drew: Es hört sich so an, als würde es die API und die Beziehung zwischen Front-End und Back-End formalisieren, sodass jeder eine vorhersehbare, standardisierte Schnittstelle erhält.
Eva: Genau.
Drew: Ich denke, in Organisationen, in denen das Frontend und das Backend verschiedenen Teams gehören, was überhaupt nicht ungewöhnlich ist. Ich denke, dieser Ansatz ermöglicht auch Änderungen, sagen wir am Frontend, es könnte anders sein Daten, ohne jemanden zu benötigen, der am Backend arbeitet, um die entsprechenden Änderungen vorzunehmen. Sie haben immer noch diese nahezu unbegrenzt anpassbare API, ohne dass Änderungen vorgenommen werden müssen, wenn Sie neue Daten benötigen.
Eve: Ja, genau richtig.
Drew: Ist also der GraphQL-Server für die Formatierung der Antwort verantwortlich, oder müssen Sie das in Ihrer serverseitigen Logik tun?
Eve: Der GraphQL-Server definiert also zwei Dinge. Es definiert das Schema selbst, das auf dem Server lebt, und dann definiert es die Resolver-Funktionen. Das sind Funktionen, die die Daten von überall abrufen. Wenn ich also eine REST-API habe, die ich mit GraphQL verpacke, würde der Resolver von dieser API abrufen, die Daten wie erforderlich transformieren und sie dann in dieser Funktion an den Client zurückgeben. Sie können auf diesem Server auch jede Art von Datenbankfunktionen verwenden, die Sie möchten. Wenn Sie also Daten an vielen verschiedenen Orten haben, ist dies ein wirklich schöner, zusammenhängender Ort, um all diese Daten einzufügen und die ganze Logik um die Frage herum zu entwerfen: „Wo kommen diese Daten her? Wie wollen wir es transformieren?“
Drew: Der Client sagt: „Ich möchte einen komplexen Benutzer“, der Server erhält das in einer Abfrage und könnte sagen: „Richtig, ich werde den komplexen Benutzer-Resolver nachschlagen.“ Ist das richtig?
Eve: Mm-hmm (bestätigend).
Drew: Welches ist die Funktion, und dann schreiben Sie Ihre Logik, damit Ihr Backend-Team oder wer auch immer die Logik in diese Funktion schreibt, alles Notwendige tut, um einen komplexen Benutzer zurückzugeben.
Eva: Ja, genau.
Drew: Das könnte also das Aufrufen anderer APIs sein, es könnte eine Datenbank abfragen, es könnte Dinge im Cache nachschlagen oder so ziemlich alles.
Eve: So ziemlich alles. Und dann, solange diese Rückgabe von der Funktion den Anforderungen des Schemas entspricht, passt, welche Felder, welche Typen dort zurückgegeben wurden, dann wird alles gut und harmonisch funktionieren.
Drew: Ich denke, es gibt Ihnen standardmäßig ein konsistentes Antwortformat über Ihre gesamte API hinweg. Sie müssen nicht entwerfen, wie das aussieht. Sie erhalten nur ein konsistentes Ergebnis.
Eva: Ja, genau.
Drew: Ich denke, das könnte wirklich ein ziemlicher Gewinn sein, denn es kann wirklich schwierig sein, die Konsistenz über eine große Bandbreite von API-Endpunkten hinweg aufrechtzuerhalten, insbesondere in größeren Teams. Verschiedene Leute arbeiten an verschiedenen Dingen. Wenn Sie keine recht strenge Governance haben, kann es sehr schnell sehr komplex werden, oder?
Eva: Ja, absolut. Und ich denke, dass Schema einfach so ein nettes kleines Dokument ist, um alles zu beschreiben. Sie haben automatisch den Vorteil, dass Sie alle Felder in diesem Schema sehen können, wenn Sie versuchen, Abfragen daran zu senden, da Sie Selbstbeobachtungsabfragen senden können und es dafür alle möglichen netten Tools wie GraphQL und GraphQL Playground gibt. kleine Tools, die Sie verwenden können, um mit den Daten der API zu interagieren.
Eve: Aber auch, wenn Sie jemals mit Postman herumgespielt haben, gerne eine REST-API anpingen, viele davon, die Dokumentation existiert nicht wirklich oder ist schwer zu finden, oder ähnliches. GraphQL gibt Ihnen wirklich diese schöne zusammenhängende Schicht, um alles zu beschreiben, was Teil dieser API sein könnte.
Drew: Wie funktionieren die Dinge praktisch auf der Serverseite? Ich meine, ich schätze, Sie müssen einen GraphQL-Dienst als Teil Ihrer Infrastruktur betreiben, aber wie sieht das aus? Ist es ein ganzer Server, der auf einem eigenen Port läuft? Oder ist es wie eine Bibliothek, die Sie in Ihren vorhandenen Express oder Apache oder was auch immer integrieren, mit einer Route, die zu diesem Dienst auflöst? Wie setzen Sie es um?
Eve: Ja, es ist ein richtiger Server. Die beliebtesten GraphQL-Implementierungen sind also Node.js-Server. Als GraphQL als Spezifikation veröffentlicht wurde, veröffentlichte das Team diese Referenzimplementierung in JavaScript, eine Art Node-Server, der als Richtlinie für all diese anderen diente, die aufgetaucht sind. Aber ja, Sie können diese Server auf ihren eigenen Instanzen ausführen. Sie können sie auf Lambda setzen. Es gibt also Apollo Server Express, es gibt Apollo Server Lambda; alle möglichen Arten von Implementierungen, die Sie verwenden können, um dieses Ding tatsächlich auszuführen.
Drew: Sie haben also kurz zuvor das Konzept eines Schemas erwähnt, das der Server hat.
Eva: Ja.
Drew: Das gibt Ihnen die Möglichkeit, Ihre Typen strenger zu beschreiben, als nur einen Namen einem Resolver zuzuordnen. Da steckt mehr dahinter, oder?
Eva: Ja. Es gibt eine vollständige Sprache. Also habe ich auf die Spezifikation verwiesen und nicht beschrieben, was es ist. GraphQL selbst ist eine Spezifikation, die die Abfragesprache und die Schemadefinitionssprache beschreibt. Es hat also eine eigene Syntax. Es hat seine eigenen Regeln zum Definieren dieser Typen.
Eve: Wenn Sie die Schema-Definitionssprache verwenden, verwenden Sie im Grunde alle Funktionen dieser Sprache, um darüber nachzudenken, welche Typen Teil der API sind? Hier definieren Sie auch die Abfragen, die Mutationen, die die Verben sind, wie die Aktionen, die Kontoanmeldung erstellen, solche Sachen. Und sogar GraphQL-Abonnements, die eine weitere coole Sache sind, Echtzeit-GraphQL, das Sie direkt im Schema definieren können.
Eve: Also ja, das Schema ist wirklich super wichtig. Und ich denke, dass es uns diese nette Typendurchsetzung in unserer gesamten Stack-Anwendung gibt, denn sobald Sie anfangen, von diesen Feldern und Typen abzuweichen, sehen Sie Fehler, was in diesem Fall gut ist, weil Sie befolgen die Regeln des Schemas.
Drew: Gibt es eine Überschneidung zwischen dem und TypeScript? Gibt es da eine Art Synergie zwischen den beiden?
Eva: Absolut. Wenn Sie also eine Person sind, die viel über GraphQL spricht, werden Ihnen die Leute manchmal sagen, dass es schlecht ist, und sie werden öffentlich auf Sie zukommen, wenn Sie das tun könnten, und darüber sprechen, dass GraphQL nicht gut ist. Aber oft überspringen sie die coolen Sachen, die man von Typen bekommt. Was die Synergie mit TypeScript betrifft, können Sie auf jeden Fall Typen für Ihre Front-End-Anwendung automatisch generieren, indem Sie die Typen aus dem Schema verwenden. Das ist also ein großer Gewinn, weil Sie es nicht nur beim ersten Mal generieren können, was Ihnen eine hervorragende Interoperabilität mit Ihrer Front-End-Anwendung bietet, sondern auch, wenn sich die Dinge ändern, Typen neu generieren und dann erstellen können, um diese Änderungen widerzuspiegeln. Also ja, ich denke, diese Dinge passen wirklich gut zusammen, da Typen beginnen, eine Art De-facto-Regel zu sein.
Eve: … um so eine Art De-facto-Regel in JavaScript zu sein, sie passen gut zusammen.
Drew: Es scheint eine Art fortlaufendes Thema bei der Art und Weise zu sein, wie TypeScript entworfen wurde … das ist nicht TypeScript, sorry. GraphQL wurde so konzipiert, dass es viel darum geht, die Interaktion zwischen dem Frontend und dem Backend zu formalisieren. Und es kommt als eine Lösung dazwischen, die nur Konsistenz schafft und eine Formalisierung dessen, was bisher für viele Menschen eine ziemlich holprige Erfahrung mit Ruhe war. Eine Sache, die wir beim Schreiben clientseitiger Apps immer im Hinterkopf behalten müssen, ist, dass der Code überprüft und möglicherweise geändert werden kann. Und eine API zu haben, bei der der Client einfach Daten anfordern kann, könnte gefährlich sein. Wenn Sie jetzt angeben können, welche Felder Sie möchten, könnte das gefährlich sein. Wo in der Art des gesamten Stapels würden Sie sich mit der Autorisierung von Benutzern befassen und sicherstellen, dass die Geschäftsregeln rund um Ihre Daten durchgesetzt werden?
Eve: Du würdest das alles auf dem Server erledigen. Das kann also auf viele verschiedene Arten geschehen. Sie müssen keine einmalige Strategie verwenden, aber Ihre Resolver kümmern sich um Ihre Autorisierung. Das könnte also bedeuten, eine vorhandene Off-REST-API zu umschließen, z. B. einen Dienst wie Auth0 oder etwas, das Sie selbst erstellt haben. Das könnte bedeuten, mit einem OAuth wie GitHub oder Facebook oder Google-Login zu interagieren, diese Art von Dingen, die das Hin- und Hergeben von Token mit Resolvern beinhalten. Aber oft wird das direkt in das Schema eingebaut. Das Schema sagt also, ich weiß nicht, wir erstellen eine Login-Mutation. Und dann sende ich diese Mutation mit meinen Anmeldeinformationen und dann werden alle diese Anmeldeinformationen auf dem Server verifiziert. Der Client muss sich also nicht so viele Gedanken machen, vielleicht ein bisschen Tokens übergeben und solche Sachen. Aber das meiste davon ist einfach in den Server eingebaut.
Drew: Im Grunde genommen ändert sich das nicht wirklich im Vergleich dazu, wie wir im Moment Erholungsendpunkte erstellen. Rest als Technologie, nun ja, es geht auch nicht wirklich um Autorisierung und wir haben Middleware und Dinge auf dem Server, die sich damit befassen. Und genauso ist es mit GraphQL. Du gehst einfach damit um. Gibt es dafür Konventionen in der GraphQL-Community? Gibt es gemeinsame Ansätze oder ist es ganz unterschiedlich, wie die Menschen sie umsetzen?
Eve: Es ist ehrlich gesagt überall. Ich denke, dass Sie meistens Leute sehen werden, die in das Schema einbauen, und damit meine ich, dass sie diese Typen und autorisierten Benutzer im Vergleich zu normalen Benutzern darstellen, die diese Typen in das Schema selbst einbauen. Aber Sie werden auch viele Leute sehen, die Lösungen von Drittanbietern verwenden. Ich erwähnte Auth0. Viele Leute werden ihre Genehmigung an Unternehmen abgeben, die sich mehr darauf konzentrieren, insbesondere kleinere Unternehmen, Startups und solche Dinge. Aber Sie werden auch sehen, wie größere Unternehmen damit beginnen, Lösungen dafür zu entwickeln. AWS, Amazon hat also AppSync, das ist ihre Variante von GraphQL, und sie haben direkt in AppSync integrierte Autorenrollen. Und das ist irgendwie cool, einfach in der Lage zu sein, ich weiß nicht, mich nicht um all dieses Zeug kümmern zu müssen oder zumindest eine Schnittstelle bereitzustellen, um damit zu arbeiten. Viele dieser Ökosystem-Tools haben also meiner Meinung nach ein so großes Thema in GraphQL. Sie haben den Bedarf, die Nachfrage nach Authentifizierungslösungen und Standardansätzen zur Handhabung von Authentifizierungen in der Grafik gesehen.
Drew: Ich denke, es gibt kaum eine Implementierung, die nicht irgendeine Art von Autorisierung benötigt. Also ja, es wird eine ziemlich häufige Anforderung sein. Wir alle bauen zunehmend komponentenbasierte Anwendungen, insbesondere wenn wir Dinge wie React und View und was auch immer verwenden. Und das Prinzip der losen Kopplung lässt uns mit vielen Komponenten zurück, die nicht unbedingt wissen, was sonst noch auf der Seite um sie herum läuft. Besteht dadurch die Gefahr, dass am Ende viele Komponenten dieselben Daten abfragen und mehrere Anfragen stellen? Oder ist es nur ein architektonisches Problem in Ihrer App, das Sie dafür lösen müssen? Gibt es bewährte Lösungen, um damit umzugehen?
Eve: Nun, ich denke, weil GraphQL zum größten Teil nicht 100% der Lösungen, aber fast jede GraphQL-Anfrage über HTTP gesendet wird. Wenn Sie also herausfinden möchten, wo diese mehreren Anfragen stattfinden, ist dies wahrscheinlich ein ziemlich bekanntes Problem für Leute, die Restdaten für ihre Anwendungen verwenden. Es gibt also einige Tools wie Paulo Client Dev Tools und Urkel Dev Tools für Frontend-Entwickler, die fragen: „Was ist los? Welche Abfragen befinden sich auf dieser Seite?“ Das gibt Ihnen wirklich klare Einblicke in das, was passiert. Dazu gibt es mehrere Denkschulen. Erstellen wir eine große, riesige Abfrage für alle Daten der Seite? Oder erstellen wir kleinere Abfragen, um Daten für verschiedene Teile der App zu laden? Beide haben, wie Sie sich vielleicht vorstellen können, ihre eigenen Nachteile, denn wenn Sie eine große Abfrage haben, warten Sie auf mehr Felder.
Eve: Bei kleineren Abfragen kann es zu Kollisionen zwischen den benötigten Daten kommen. Aber ich denke, und um nicht zu sehr auf die Spitze zu treiben, aber ich bin schon da. Es gibt also etwas namens Deferred Directive, das in die GraphQL-Spezifikation kommt, und die Deferred Directive wird dabei helfen, Inhalte sekundär zu laden. Nehmen wir also an, Sie haben einige Inhalte oben auf der Seite, die superwichtigen Inhalte, die Sie zuerst laden möchten. Wenn Sie dies zu Ihrer Abfrage hinzufügen, erhalten alle nachfolgenden Felder die verzögerte Anweisung dazu. Es ist nur ein kleiner Decorator, den Sie einem Feld hinzufügen würden, der dann sagt: "In Ordnung, laden Sie zuerst die wichtigen Daten, dann halten Sie hoch und laden Sie die zweiten Daten als zweites." Und es gibt Ihnen das, es ist das Aussehen einer Art Streaming-Daten an Ihr Frontend, so dass es eine wahrgenommene Leistung gibt, es gibt Interaktivität. Die Leute sehen die Daten sofort, anstatt darauf zu warten, dass jedes einzelne Feld für die Seite geladen wird, was ja, es könnte ein Problem sein.
Drew: Ja. Ich schätze, das ermöglicht es Ihnen, Seiten zu entwerfen, auf denen alles, was … wir reden nicht gerne zu viel über den Viewport, aber es ist alles, was über der Falte liegt, Sie könnten Prioritäten setzen, diese Last hinein haben und dann sekundär alles weitere einladen Nieder. Wir haben also viel über das Abfragen von Daten gesprochen. Eine der Hauptaufgaben einer API besteht darin, neue und geänderte Daten zur Persistenz an den Server zurückzusenden. Sie haben vorhin kurz Mutationen erwähnt. Das ist die Terminologie, die GraphQL verwendet, um Daten zurück auf den Server zu schreiben?
Eva: Genau. Also jede Art von Änderungen, die wir an den Daten vornehmen wollen, alles, was wir auf den Server zurückschreiben wollen, das sind Mutationen, und das sind alles genau wie Abfragen, sie sind benannte Operationen, die auf dem Server leben. Sie können also darüber nachdenken, was all die Dinge sind, die wir unseren Benutzern ermöglichen sollen? Stellen Sie diejenigen mit Mutationen dar. Und schreiben Sie dann wieder auf dem Server alle Funktionen, die das Zeug zum Laufen bringen.
Drew: Und ist das genauso einfach wie das Abfragen von Daten? Das Aufrufen einer Mutation ist genauso einfach?
Eva: Ja. Es ist Teil der Abfragesprache. Es sieht ziemlich identisch aus. Der einzige Unterschied ist, nun, ich denke, Abfragen nehmen Filter auf. Also Mutationen, die wie Filter in der Abfrage selbst aussahen. Aber diese sind dafür verantwortlich, Daten tatsächlich zu ändern. Eine E-Mail und ein Passwort werden möglicherweise mit einer Mutation gesendet, und der Server sammelt diese und verwendet sie dann, um den Benutzer zu autorisieren.
Drew: Also, genau wie zuvor, erstellen Sie einen Resolver im Backend, um damit umzugehen und alles zu tun, was getan werden muss. Beim Schreiben von Daten kommt es häufig vor, dass Sie Ihre Änderungen festschreiben und dann erneut abfragen möchten, um den aktuellen Status zu erhalten. Hat GraphQL dafür einen guten Workflow?
Eve: Es lebt gewissermaßen in der Mutation selbst. Wenn Sie also Ihr Schema erstellen, erstellen Sie häufig die Mutationsoperation. Ich bleibe beim Login, nehme die E-Mail und das Passwort auf. Und die Mutation selbst hat etwas zurückgegeben. Es könnte also etwas so Einfaches wie einen booleschen Wert zurückgeben, das lief gut oder das lief schlecht, oder es könnte einen tatsächlichen Typ zurückgeben. So oft sehen Sie die Mutation wie die Login-Mutation, vielleicht gibt sie einen Benutzer zurück. Sie erhalten also alle Informationen über den Benutzer, sobald er angemeldet ist. Oder Sie können einen benutzerdefinierten Objekttyp erstellen, der Ihnen diesen Benutzer sowie die Uhrzeit der Anmeldung des Benutzers und möglicherweise etwas mehr Metadaten zu dieser Transaktion im Rückgabeobjekt liefert . Also noch einmal, es liegt an Ihnen, das zu entwerfen, aber dieses Muster ist wirklich in GraphQL eingebrannt.
Drew: Das klingt alles ziemlich gut, aber jede technische Entscheidung beinhaltet Kompromisse. Was sind die Nachteile der Verwendung von GraphQL? Gibt es Szenarien, in denen es eine wirklich schlechte Wahl wäre?
Eve: Ich denke, dass der Ort, an dem ein GraphQL Probleme haben könnte, darin besteht, eine Eins-zu-Eins-Karte von
Eve: … der Kampf besteht darin, eine Eins-zu-eins-Karte tabellarischer Daten zu erstellen. Nehmen wir also an, Sie haben, ich weiß nicht, eine Datenbanktabelle mit allen möglichen verschiedenen Feldern und, ich weiß nicht, Tausenden von Feldern eines bestimmten Typs, solche Dinge, dieser Datentyp kann gut dargestellt werden mit GraphQL, aber manchmal, wenn Sie einen Prozess ausführen, um ein Schema für diese Daten zu generieren, bleiben in einem Schema die gleichen Probleme zurück, die Sie in der Datenbank hatten, was möglicherweise zu viele Daten sind, die über das hinausgehen, was der Client kann eigentlich verlangt. Also denke ich, dass diese Orte potenzielle Probleme sind. Ich habe mit Leuten gesprochen, die Schemas basierend auf ihren Daten automatisch generiert haben, und es ist ein Millionen Zeilen langes Schema oder so etwas geworden, nur Tausende und Abertausende von Zeilen Schemacode. Und hier wird es ein wenig knifflig, wie nützlich ist dies als ein für Menschen lesbares Dokument?
Eva: Ja. Jede Art von Situation, in der Sie es mit einem Kunden zu tun haben, passt wirklich gut, wenn es darum geht, alle unterschiedlichen Datentypen zu modellieren. Es wird ein wenig schwierig, wenn Ihre Datenquellen zu groß sind.
Drew: Es hört sich so an, als ob Sie überall dort, wo Sie die Antworten in den Feldern sorgfältig kuratieren und dies mehr von Hand tun, wirklich beeindruckende Ergebnisse erzielen können. Aber wenn Sie Dinge automatisch generieren, weil Sie gerade ein riesiges Schema haben, dann wird es vielleicht ein wenig unhandlich.
Eva: Ja. Und ich denke, die Leute hören mir zu und widersprechen mir da, weil es dafür auch gute Werkzeuge gibt. Aber ich denke, der Punkt, an dem GraphQL wirklich glänzt, ist der Schritt, Logik auf den Server zu abstrahieren, Front-End-Entwicklern die Freiheit zu geben, ihre Komponenten oder ihre Front-End-Datenanforderungen zu definieren und das Schema wirklich als Team zu verwalten.
Drew: Ist irgendetwas in die Abfragesprache eingebaut, um mit der Paginierung der Ergebnisse umzugehen, oder hängt das von einer benutzerdefinierten Implementierung nach Bedarf ab?
Eva: Ja. Paginierung würden Sie zuerst in das Schema einbauen, damit Sie dafür die Paginierung definieren könnten. Es gibt eine Menge Richtlinien, die in der Community entstanden sind. Ein gutes Beispiel dafür, ob Sie neu bei GraphQL sind oder nicht, ich schaue mir das ständig an, ist die GitHub GraphQL API. Sie haben ihre API für v4 ihrer öffentlich zugänglichen API im Grunde mit GraphQL neu erstellt. Das ist also ein guter Ort, um sich anzusehen, wie ein wirklich großes Unternehmen dies in großem Umfang einsetzt. Viele Leute haben große APIs am Laufen, aber sie machen sie nicht für alle öffentlich. Die Paginierung ist also wirklich gut in diese API integriert, und Sie können, ich weiß nicht, die ersten 50 Repositories zurückgeben, die Sie jemals erstellt haben, oder Sie können auch eine Cursor-basierte Paginierung verwenden, um Datensätze basierend auf Ideen in Ihren Daten zurückzugeben. Also Cursor-basierte Paginierung und eine Art Positions-Paginierung wie erster, letzter Datensatz, das ist normalerweise die Art und Weise, wie die Leute das angehen, aber es gibt viele Techniken.
Drew: Gibt es große Fallstricke, die wir bei der Verwendung von GraphQL kennen sollten? Angenommen, ich bin dabei, eine neue GraphQL-Installation für meine Organisation bereitzustellen, werden wir in Zukunft alle unsere neuen API-Endpunkte mit GraphQL erstellen. Was sollte ich wissen? Lauert irgendetwas in den Büschen?
Eve: Im Gebüsch lauern, immer mit Technik, oder? Ich denke, eines der Dinge, die nicht in GraphQL integriert sind, aber ohne allzu großen Aufwand implementiert werden können, ist die API-Sicherheit. Sie haben beispielsweise erwähnt, dass wir mit Genehmigung darüber gesprochen haben, wenn ich eine große Abfrage habe, aber es ist auch beängstigend, eine API zu öffnen, an die jemand einfach eine große verschachtelte Abfrage senden könnte, Freunde von Freunden, Freunde von Freunden, Freunde von Freunden , die Kette runter und runter. Und dann erlauben Sie den Leuten im Grunde, Sie mit diesen riesigen Abfragen zu beschimpfen. 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. Hast du Abschiedsworte?
Eve: Parting words, have fun with GraphQL, take the plunge, you'll enjoy it, and thanks so much for having me. I appreciate it.