Why GraphQL?

In diesem Video möchte ich mir ein paar Minuten Zeit nehmen, um eine wichtige Frage zu untersuchen. Die wohl wichtigste Frage, die wir derzeit haben, ist, warum Grafik. F Nun, wir werden viel Zeit miteinander verbringen, um dieses neue Tool zu lernen. Wir möchten also sicherstellen, dass die Zeit in diesem Video gut angelegt ist. Wir werden darüber sprechen, wo das Transplantat in unsere Anwendungen passt. Wir werden einige der Vorteile der Verwendung von Diagrammen untersuchen. Nun und zum Schluss werden wir darüber sprechen, warum es so ein beliebtes Werkzeug geworden ist. Zum Auftakt möchte ich darüber sprechen, wo das Transplantat gut in unsere Anwendung passt. Wenn Sie wie die meisten Menschen sind, verwendet Ihre aktuelle Anwendung wahrscheinlich eine Art Rest-API, bei der Sie HTP-Aufrufe zwischen Ihrem Client und dem Server tätigen, um Daten zu senden und zu empfangen, oder Ihre Anwendung verfügt wahrscheinlich über mindestens einen Client. Ich werde weitermachen und sagen, dass wir für unser fiktives Beispiel einige verschiedene Kunden haben. Nehmen wir an, wir haben eine Webanwendung, in der sich Benutzer anmelden können, um ihre Daten zu verwalten, und wir geben ihnen auch eine mobile Anwendung für iOS und eine für Android, die sie unterwegs mitnehmen können. Jetzt repräsentieren diese drei Kunden nur noch einen Teil unseres gesamten Anwendungsstapels. Wir haben auch mindestens unseren Server und unsere Datenbank. Lassen Sie uns diese auch hier vertreten. Vielleicht verwenden wir kein J. S. Mit der Mongo D-B-Datenbank verwenden wir vielleicht Python mit der Post-Gresse-Datenbank oder Java mit meiner Frage-Eule. Es spielt keine Rolle. Eine beliebige Anzahl von Client-Telefonen, Fernsehgeräte, Laptops können mit einer beliebigen Anzahl von Servern kommunizieren, da der Klebstoff zwischen den beiden immer Standard-HTP-Anforderungen waren, die normalerweise als eine Art Ruhe-API oder Ruhe dargestellt werden. Die API hat möglicherweise ein Dutzend verschiedene Endpunkte, die für die Kommunikation mit dem Server verwendet werden können. Vielleicht haben wir eine, um eine andere für die Anmeldung anzumelden, und sagen wir, wir erstellen eine Blogging-Anwendung, also haben wir eine, um einen neuen Beitrag zu erstellen, und eine, um alle verfügbaren Beiträge in der Datenbank zu lesen. Dies ist ein ziemlich typischer Aufbau, wenn wir das Transplantat einführen. Nun, nicht viel wird sich ändern. Wir werden weiterhin jeden Client verwenden können und wir werden weiterhin jeden Server verwenden können, obwohl wir uns in diesem Kurs auf Node J Ass konzentrieren werden. Alles, was wir tun werden, ist, unsere Rest-API durch viele Endpunkte durch eine Diagramm-API zu ersetzen, die nur ein einziges Endpunkt-Diagramm enthält. L steht für die Graph-Abfragesprache und dies funktioniert auch über HTP. Dies bedeutet, dass wir jede gewünschte Back-End-Sprache mit jeder gewünschten Datenbank und jeden gewünschten Client verwenden können. Vielleicht haben wir eine Web- und eine mobile App. Möglicherweise müssen wir auch von einem anderen Server aus mit dieser Diagramm-API kommunizieren. Das ist auch vollkommen in Ordnung. Grafik L ist super flexibel und wir werden dies während des gesamten Kurses sehen. Im nächsten Schritt möchte ich kurz erläutern, warum Grafik etwas ist, das Sie in Betracht ziehen sollten, wenn Sie ein Burst-Up-Diagramm verwenden. Gut ist schnell und um dies zu untersuchen, möchte ich ein typisches Beispiel dafür durchgehen, wie es aussehen könnte, die für eine Seite erforderlichen Daten mit einer Rest-API und dann mit einer grafischen API zu laden. Nehmen wir also an, wir beginnen mit dem restlichen AAPI-Beispiel. Wir haben immer noch einen Kunden. Sagen wir einfach, es ist ein Browser und wir haben unseren Server als Klebstoff zwischen den beiden. Ist dies die Standard-Rest-API, bei der wir ungefähr ein Dutzend verschiedene Endpunkte für die Verwaltung unserer Anwendungsdaten haben? Lassen Sie uns fortfahren und einige HTP-Anfragen zum Rendern einer Seite stellen. Nehmen wir an, diese Seite ist eine Seite zum Lesen eines Blogposts. Wir brauchen also den Titel des Beitrags und den Körper des Beitrags. Wie bekommen wir die? Wir stellen eine HTP-Anfrage, die ein bisschen so aussehen könnte. Wir stellen eine Anfrage an folgende Personen: Sie sind L .. Schrägstrich vorwärts vorwärts Schrägstrich 1 bis 3, wobei 1 bis 3 diese Beitrags-ID ist. Der Server wird dies analysieren, Arel wird die richtigen Daten finden und sie zurücksenden. Wahrscheinlich in Form von Jason. Der Server antwortet also mit so etwas wie. Hier sind die Post-Details. Jetzt werden die Post-Details auf der Seite gerendert und wir stellen fest, dass wir ein bisschen mehr Informationen wollen. Ich möchte am Ende des Beitrags auch andere Beiträge dieses Autors anzeigen, da ich die Leute auf der Website halten möchte. Ich möchte ihnen etwas zum Lesen geben, wenn sie fertig sind, was sie gerade lesen. Wenn ich mehr Daten benötige, stelle ich hier eine weitere Anfrage. Ich kann hier eine zweite HTP-Anfrage an so etwas wie Schrägstrich-Posts weiterleiten. Ich verwende eine Abfragezeichenfolge, um nach dem Post-Autor zu filtern. Ich möchte nur Beiträge mit der folgenden Autoren-ID 3 4 bis 1 finden. Nur ein erfundener Ausweis. Nehmen wir an, dies ist die Autoren-ID des Beitrags, den wir vom Server abgerufen haben, um all dies zu analysieren. Es wird versucht, andere Beiträge dieses Autors zu finden, und es wird sie zurückschicken, damit wir einige davon am Ende der Beitragsseite korrekt rendern können. Nehmen wir jetzt an, wir müssen nur noch eines brauchen. Kommentare für diesen Beitrag, damit wir diese auch unten anzeigen können. Denn hier werden wir unsere dritte und letzte Anfrage für eine andere Ressource stellen. Hier machen wir immer noch die Anfrage, Schrägstrich-Posts weiterzuleiten. Schrägstrich 2:59 die Post-ID weiterleiten Schrägstrich-Kommentare. Wir bekommen also alle Kommentare für diesen Beitrag. Dies ist eine ziemlich standardmäßige Arrest-API, die Sie RL-Struktur. Wieder geht der Server aus. Es analysiert dies und sendet die Daten zurück. Und schließlich haben wir alles, was wir brauchen. Wir können alles auf den Bildschirm rendern, um dem Benutzer die bestmögliche Erfahrung zu bieten. Nun wollen wir sehen, wie wir genau dieselben Daten abrufen können, um unsere Blogpost-Seite zu rendern, aber eine grafische API verwenden. Wir möchten also weiterhin Details wie Titel und Text veröffentlichen. Ich möchte immer noch andere Beiträge dieses Autors und ich möchte immer noch die Kommentare hier. Wir haben einen Client, wir haben einen Server. Diesmal aber gut pfropfen wie der Kleber zwischen den beiden. Und denken Sie an Grafiken, die Sie alle über HTP bedienen können. Letztendlich stellen wir also immer noch nur HTP-Anfragen. Lass uns weitermachen und unseren ersten machen. Abrufen der für diese Seite erforderlichen Daten. Jetzt wird die Anfrage, die wir stellen werden, eine Post-Anfrage sein und die grafische Lebensqualität zeigt nur einen einzigen Endpunkt. Das ist ein sehr wichtiger Teil des Puzzles. Jetzt hättest du das so nennen können, wie du willst. In diesem Beispiel habe ich es Transplantat gut genannt, aber wir werden sehen, wie man das im Verlauf des Kurses umbenennt. Hier ist der Haken bei unserer Anfrage. Wir werden ein Diagramm senden, das er abfragt. Ein Diagramm, das Sie abfragen, lässt den Client genau beschreiben, welche Daten er vom Server benötigt. Der Server stellt dann alle diese Daten bereit und sendet sie zurück, damit der Client sie genau beschreiben kann was es braucht und es bekommt diese Daten nicht mehr und nicht weniger. Dies ist ein sehr mächtiger Teil des Puzzles. Anstatt dass der Server bestimmt, welche Daten zurückgesendet werden, muss der Client alle benötigten Daten anfordern. In diesem Fall kann ich also die Postdetails anderer Posts dieses Autors anfordern. Irgendwelche Post-Kommentare. Alle mit einem einzigen Transplantat werden jetzt die Magie hinter all dem anfordern, ist diese Grafik. Nun, Queery, aber darüber werden wir in diesem Video eigentlich nicht sprechen, obwohl es ein Hauptthema des Kurses ist und wir sehr bald darauf zurückkommen werden. Im Moment müssen wir nur wissen, dass der Client bestimmen kann, welche Daten er zurückerhält, im Gegensatz zu einem herkömmlichen Arrest-API-Endpunkt, bei dem der Server bestimmt, welche Daten von einem Endpunkt zurückkommen. Jetzt sind drei Anfragen eindeutig mehr als eine Anfrage. Am Ende des Tages wird Grath also schneller sein und es wird uns ermöglichen, alle Daten, die wir benötigen, mit einer HTP-Anfrage abzurufen. Rod Speed allein reicht nicht aus, um ein Tool nützlich zu machen. Und obwohl das ein Vorteil von Graft ist, ist es meiner Meinung nach definitiv nicht der größte Vorteil. Der größte Vorteil ist die Flexibilität des Transplantats gut. Mit diesem letzten Beispiel hätten Sie leicht argumentieren können, dass der Rest-API-Teil des Beispiels vollständig erfunden wurde. Ich habe mich absichtlich dafür entschieden, drei Anfragen anstelle einer zu stellen. Offensichtlich ist drei größer als eins. Es wird natürlich etwas langsamer, aber ich habe diese Entscheidung getroffen, um diesen Punkt zu beweisen. Wir könnten absolut alle drei und Punkte in einen packen. Schauen wir uns also hier unser Rest-API-Beispiel noch einmal an. Wir haben unseren Client unsere Server Rest API ist der Kleber. Wir stellen hier unsere einzige HTP-Anfrage. Ich verwende nur den ersten Endpunkt, den wir hatten. Wir bekommen die Post per ID. Und was bekommen wir zurück? Wir bekommen alles zurück, was wir über unsere Post-Details erfahren, nämlich den Titel und den Text. Wir bekommen die Kommentare für den Beitrag und wir bekommen andere Beiträge vom Autor. Dies wäre ein perfekter Ansatz. Es würde dem Client alles geben, was er zum Rendern dieser Seite mit nur einer einzigen HTP-Anforderung benötigt. Und das Problem bei dieser Lösung ist, dass wir jetzt diesen einen Endpunkt haben, der weit mehr Datenbankanforderungen stellt als zuvor. Es wird groß und langsam. Möglicherweise wurde eine Datenbankanforderung gestellt, um mindestens drei Anforderungen zu stellen, um alle erforderlichen Daten zu erhalten. Für die Desktop-Version unserer App, die möglicherweise in Ordnung ist, werden wir möglicherweise alle Daten sofort verwenden. Also lass es uns einfach bekommen. Was aber, wenn eine mobile Version unserer Anwendung dasselbe Back-End verwenden soll? Wir stellen die HTP-Anfrage an Sie und das Problem ist, dass die mobile Anwendung die Daten nicht ändern kann. Es wird wieder auf mobilen Geräten. Wir haben ganz andere Überlegungen. Wir haben weniger Bildschirmimmobilien. Wir müssen uns um die Akkulaufzeit sorgen. Wir haben langsame und teure Daten. Wir möchten sicherstellen, dass wir das Gerät nicht missbrauchen, da die Benutzer sonst eine schlechte Benutzererfahrung erhalten. Die App wird Genki fühlen und sie werden wahrscheinlich deinstalliert. Dies ist eigentlich der ursprüngliche Grund, warum ein Transplantatbrunnen geschaffen wurde. Facebook hatte das gleiche Problem wie eine Desktop-Version der Anwendung wie eine mobile Version der Anwendung und sie brauchten nicht immer die gleichen Daten für beide. Sie wollten eine flexible Möglichkeit für die einzelnen Kunden, genau die Daten anzufordern, die sie nicht mehr und nicht weniger verwenden würden. Vielleicht möchten wir die Kommentare auf dem mobilen Gerät erst laden, wenn jemand auf eine Schaltfläche am unteren Rand des Beitrags klickt, z. B. Kommentar anzeigen mit einer Lösung, die nicht wirklich wichtig ist, da die Kommentare bereits geladen wurden. Es wäre schöner, wenn wir die Kommentare später bei Bedarf abrufen könnten. Desktop- und Mobilgeräte haben also unterschiedliche Anforderungen. Dies ist kein Problem, auf das wir mit der Transplantat-UL-API auf dem Desktop stoßen werden. Wir führen eine grafische UL-Abfrage durch und geben an, dass wir alle diese Informationen benötigen. Wir benötigen den Beitrag selbst, wenn Sie die Kommentare in anderen Beiträgen des Autors und auf unserem Mobilgerät hinzufügen. Was machen wir. Wir stellen eine HTP-Anfrage an denselben Endpunkt mit einer anderen grafischen Abfrage. In diesem Fall sagen wir, dass wir möglicherweise nur Details veröffentlichen müssen, damit wir nur die Post-Details zurückerhalten. Bei der Website-Version unserer Anwendung, bei der die Abfrage nach vielen Daten fragt, muss der Server also viel Arbeit leisten, um die drei oder so Datenbankanforderungen zu erfüllen, die erforderlich sind, um alles abzurufen. Das Schöne ist jedoch, dass in der mobilen Version der Anwendung, in der die Abfrage nach weniger Daten fragt, der Server weniger Arbeit leistet. In diesem Fall hatten wir nicht die gleiche Flexibilität, da die Datenbankanforderung 1 erforderlich war, um den Post-Titel und den Post-Body mit der Rest-API zu erhalten. Wir haben mit beiden die gleiche Antwort mit Grafiken. Nun, es ist der einzelne Client, der bestimmt, welche Daten er mit einer Rest-API vom Server zurückerhält. Es ist der Server, der bestimmt, welche Daten an welchen Endpunkt zurückgesendet werden, und das ist ein großer Unterschied. Ja, am Ende des Tages können Sie versuchen, Ihre Rest-API anzupassen. Fügen Sie möglicherweise Abfragezeichenfolgen hinzu, um zu bestimmen, ob Sie die Kommentare möchten oder nicht und ob Sie die anderen Beiträge dieses Autors möchten oder nicht. Aber an diesem Punkt nähern Sie sich gefährlich der Neuerstellung des Transplantats, das Sie alle bereits anbieten. Aus diesem Grund verwenden große Unternehmen wie Facebook und Get Hub heute Grafiken in der Produktion. Es bietet die Geschwindigkeit und Flexibilität, die für reale Anwendungen erforderlich sind. Wir haben also festgestellt, dass das Diagramm schnell und flexibel ist. Es ist auch einfach zu verwenden und mit der restlichen API einfach zu warten, wenn der Client andere Daten benötigt. In der Regel müssen wir einen neuen Endpunkt hinzufügen oder einen vorhandenen mithilfe eines Diagramms ändern. Nun, API. Der Client muss nur seine Abfrage ändern. Das Erstellen einer grafischen API ist nach meiner persönlichen Meinung und Erfahrung viel einfacher zu pflegen. Zu diesem Zeitpunkt haben wir definitiv mehr Fragen gestellt, als wir beantwortet haben. Zum Beispiel haben wir keine Ahnung, was eine grafische Abfrage ist oder wie wir dies einrichten werden. Und das ist im Moment in Ordnung. Wir werden uns im Detail mit all dem befassen. Wie immer etwas später in der Klasse ist das einzige, was Sie wirklich von diesem Video entfernen müssen, die folgende Grafik. Well erstellt schnelle und flexible API-Augen, sodass Kunden die vollständige Kontrolle haben, nur die Daten anzufordern, die sie benötigen. Dies führt zu weniger flexiblen Datenabfragen bei HTP-Anforderungen und im Allgemeinen zu weniger zu verwaltendem Code. Mit dieser erhöhten Geschwindigkeit und Flexibilität erhalten wir dieselben Vorteile. Ich freue mich riesig, in den Rest des Kurses einzutauchen und all dies mit einer produktionsfertigen Anwendung in der Praxis umzusetzen. Also lasst uns weitermachen und direkt zum nächsten Video springen.