Die beste (GraphQL) API ist eine, die man selbst schreibt

Hören Sie, ich bin kein GraphQL-Experte, aber ich arbeite gerne damit. Die Art und Weise, wie es mir als Frontend-Entwickler Daten zur Verfügung stellt, ist ziemlich cool. Es ist wie eine Speisekarte mit verfügbaren Daten, und ich kann nach allem fragen, was ich möchte. Das ist eine massive Verbesserung gegenüber REST und sehr ermächtigend für mich als Frontend-Entwickler, der Komponenten mit den Daten gestalten möchte, die ich für eine UI am besten halte, ohne eine Reihe von Aufrufen für Daten machen oder einen Backend-Entwickler um Hilfe bitten zu müssen, eine neue maßgeschneiderte API für meine neuen Bedürfnisse zu erstellen.

Aber… wer erstellt diese Datenspeisekarte? Jemand tut es.

Wenn dieser Jemand eine Person oder ein Team in Ihrem eigenen Unternehmen ist, weil Sie Ihre eigene GraphQL-API für Ihre eigenen Bedürfnisse erstellt haben, ist das großartig. Jetzt haben Sie die Kontrolle darüber, was hineinkommt (und wann und wie).

Aber manchmal werden GraphQL-APIs einfach an Sie übergeben. Vielleicht ist das die Art und Weise, wie Ihr CMS seine Daten liefert. Immer noch cool und nützlich, aber diese Kontrolle liegt im Ermessen des CMS. Sie haben immer noch eine Auswahl an Optionen, aber die Speisekarte ist eben, was sie ist. Keine Ersetzungen, um die Metapher fortzusetzen. Wenn die Speisekarte nicht das hat, was Sie brauchen, können Sie nicht in die Küche zurückkehren und dem Reuben extra Sauerkraut hinzufügen oder Steakfritten mit gebratenen Pilzen servieren lassen.

Das kam in einer Diskussion mit Simen Skogsrud und Knut Melvær in einer Folge von ShopTalk zur Sprache. Ihr Produkt, Sanity, ist wie Cloud-Speicher für JSON-Daten und ein CMS, wenn Sie es brauchen. Ein modernes Produkt wie dieses, man könnte meinen, eine GraphQL-API wäre ein No-Brainer, und tatsächlich haben sie eine Beta dafür.

Aber anstatt GraphQL als die wichtigste erstklassige Methode zum Abfragen und Ändern von Daten zu verwenden, haben sie ihre eigene spezielle Sprache: GROQ. Auf den ersten Blick denke ich: *eeeeeesh, da gibt es eine Möglichkeit, sich selbst ins Bein zu schießen*. Erfinde eine Sondersprache, die Leute lernen müssen und die einzigartig für dein Produkt ist, anstatt dem aufkommenden Industriestandard.

Aber Simen und Knut hatten einen guten Punkt bezüglich einiger Einschränkungen von GraphQL im Kontext einer Drittanbieter-API: Man bekommt, was man bekommt. Nehmen wir an, eine GraphQL-API bietet eine Möglichkeit, Autoren abzurufen. Eine generische API dafür ist wahrscheinlich so gestaltet

{
  allAuthors {
    author {
      name
      username
      avatar
    }
  }
}

Aber was ich eigentlich will, ist nur, *wie viele* Autoren wir auf der Website haben. Vielleicht wünsche ich mir, dass ich das tun könnte

{
  allAuthors {
    count
  }
}

Aber das ist nicht in der API, die mir gegeben wurde. Nun, zu schlecht. Ich werde wohl alle Autoren anfordern und sie selbst zählen müssen. Ich habe vielleicht keine Kontrolle über die API.

Das bedeutet, dass ein CMS, das einen GraphQL-Endpunkt anbietet, eine Entscheidung treffen muss. Entweder sind sie sehr strikt und man bekommt, was man bekommt. Oder sie bieten nicht nur eine GraphQL-API, sondern auch eine Möglichkeit, zu kontrollieren und zu erweitern, was in diese API einfließt.

Im Fall von Sanity bieten sie statt Letzterem GROQ an, eine Abfragesprache, die leistungsfähig genug ist, um alles zu bekommen, was man aus den (JSON)-Daten möchte. Und anstatt es zu einer proprietären Sanity-eigenen Sache zu machen, haben sie es Open Source gemacht.

Mit GROQ benötige ich keine Erlaubnis oder Änderungen an der API, um zu fragen, wie viele Autoren es gibt. Ich würde so etwas tun…

{ "totalAuthors": count(*[_type == "author"]) }

(Ich habe tatsächlich keine Ahnung, ob der obige Code korrekt ist, und natürlich hängt er von den JSON-Daten ab, die abgefragt werden, aber es ist nur konzeptionell.)

Indem man jemandem eine Abfragesprache gibt, die in der Lage ist, jede mögliche Daten aus dem Datenspeicher auszuwählen, hat das einen großen Vorteil

• Man kann buchstäblich alles abfragen
• Man benötigt keine mittlere Konfigurationsschicht

Aber es hat einen Preis

• Komplexität der Syntax
• Keine mittlere Schicht bedeutet weniger Möglichkeiten, mehrere APIs zu verbinden, nur bestimmte Daten basierend auf Berechtigungen preiszugeben usw.