Komponenten statt Graphen verwenden

Gato GraphQL verwendet keine Graphen zur Darstellung des Datenmodells. Stattdessen werden Komponenten eingesetzt.

Das ist kein unerwarteter Ansatz. Unter dem Titel Thinking in Graphs erklärt das GraphQL-Projekt (Hervorhebung hinzugefügt):

Graphen sind mächtige Werkzeuge zur Modellierung vieler realer Phänomene, weil sie unseren natürlichen mentalen Modellen und verbalen Beschreibungen des zugrunde liegenden Prozesses ähneln. Mit GraphQL modellierst du deine Geschäftsdomäne als Graphen, indem du ein Schema definierst; innerhalb deines Schemas definierst du verschiedene Knotentypen und wie sie miteinander verbunden sind/sich aufeinander beziehen. Auf der Client-Seite entsteht dadurch ein Muster ähnlich der objektorientierten Programmierung: Typen, die auf andere Typen verweisen. Auf der Server-Seite, da GraphQL nur die Schnittstelle definiert, hast du die Freiheit, es mit jedem Backend zu verwenden (neu oder legacy!).

Was aus dieser Definition mitgenommen werden sollte, ist Folgendes:

Auch wenn die Antwort die Form eines Graphen hat, bedeutet das nicht, dass Daten tatsächlich als Graph dargestellt werden, wenn man sie serverseitig verarbeitet. Der Graph ist nur ein mentales Modell, keine tatsächliche Implementierung.

Das ist eine gute Nachricht, denn der Umgang mit Graphen (oder Bäumen) ist nicht trivial. Komponenten hingegen sind viel einfacher zu implementieren und bieten genau dieselben Vorteile.

​

Das Datenmodell durch Komponenten vereinfachen

Komponenten zur Darstellung der Datenstruktur auf der Serverseite zu verwenden ist hinsichtlich der Einfachheit optimal, weil es erlaubt, die verschiedenen Modelle für unsere Daten in einer einzigen Struktur zusammenzufassen. Statt eines Ablaufs wie diesem:

Query aufbauen, um Komponenten zu befüllen (Client) => Daten als Graph/Baum verarbeiten (Server) => Daten an Komponenten übergeben (Client)

...sieht unser Ablauf so aus:

Komponenten (Client) => Komponenten (Server) => Komponenten (Client)

Das ist erreichbar, weil die GraphQL-Anfrage als eine Datenstruktur mit einer „Komponentenhierarchie" betrachtet werden kann, in der jeder Objekttyp eine Komponente repräsentiert und jedes Beziehungsfeld von einem Objekttyp zu einem anderen Objekttyp eine Komponente darstellt, die eine andere Komponente umschließt.

Lass uns ein Beispiel verwenden, um diese Beziehung zwischen Komponente und GraphQL-Query zu veranschaulichen. Angenommen, wir möchten das folgende Widget „Vorgestellter Regisseur" bauen:

Mit Vue oder React (oder einer anderen komponentenbasierten Bibliothek) würden wir zunächst die Komponenten identifizieren. In diesem Fall hätten wir eine äußere Komponente <FeaturedDirector> (rot), die eine Komponente <Film> (blau) umschließt, die ihrerseits eine Komponente <Actor> (grün) umschließt:

Der Pseudo-Code sieht so aus:

<!-- Component: <FeaturedDirector> -->
<div>
  Country: {country}
  {foreach films as film}
    <Film film={film} />
  {/foreach}
</div>
 
<!-- Component: <Film> -->
<div>
  Title: {title}
  Pic: {thumbnail}
  {foreach actors as actor}
    <Actor actor={actor} />
  {/foreach}
</div>
 
<!-- Component: <Actor> -->
<div>
  Name: {name}
  Photo: {avatar}
</div>Copy

Dann identifizieren wir, welche Daten für jede Komponente benötigt werden. Für <FeaturedDirector> brauchen wir name, avatar und country. Für <Film> brauchen wir thumbnail und title. Und für <Actor> brauchen wir name und avatar:

Und wir bauen unsere GraphQL-Query, um die benötigten Daten abzurufen:

query {
  featuredDirector {
    name
    country
    avatar
    films {
      title
      thumbnail
      actors {
        name
        avatar
      }
    }
  }
}Copy

Wie man sehen kann, besteht eine direkte Beziehung zwischen der obigen Komponentenhierarchie und dieser GraphQL-Query.