GraphQL ist irgendwie nervig

• GraphQL ist großartig, aber es wirkt etwas überhypt
• Anfänger bis fortgeschrittene Entwickler scheinen nach ein paar YouTube-Videos zu GraphQL zu greifen, aber das ist wohl ein Irrweg
• Vorteile
  • Gewünschte Daten lassen sich leicht beschreiben
  • Spart Bandbreite. Man kann in einem Rutsch genau so viel holen, wie man braucht
  • Es ist leicht, Dokumentation für Datenkonsumenten zu erstellen
  • Subscriptions lassen sich einfacher nutzen
  • API-Aufrufe können gebündelt werden
• Nachteile
  • In der Praxis ist es schmerzhaft. Wenn es je nach verwendetem Backend nicht für deine Sprache generiert wird, musst du zwei oder mehr Typsysteme verwalten
  • Unterstützt keine Maps/Tabellen/Dictionaries. Das ist wirklich groß. Auch wenn man es nicht will, landet man irgendwo bei {[key: string] : T}
  • Es gibt keinen klaren Weg für API-Versionierung. Am Ende macht man etwas wie MyQueryV1.01, MyQueryV1.02, MyQueryV1.03
• Wenn du nicht genau die Lösungs-/Problemmenge bearbeitest, für die Facebook GraphQL vorgesehen hat, dann benutze GraphQL nicht
• Welche klugen Worte könnten andere Senior-Entwickler sagen, um Junior-Entwickler davor zu bewahren, in diesen Sumpf zu geraten?

Kommentare auf HN

• Das größte Problem von GraphQL ist, dass man Arbeit investieren muss, um DOS-Angriffe abzuwehren oder Leute davon abzuhalten, die gesamte DB herunterzuladen.
  • Es ist sehr leicht, Queries zu bauen, die dein System unangemessen stark belasten.
  • Wenn du sehen willst, was dafür alles nötig ist, schau dir Shopify an. Dort gibt es Rate Limits für die Menge der zurückgegebenen Daten, dazu Cursor und Pagination. Anders als in den hübschen GraphQL-Beispielen im Internet ist das Schema riesig und hässlich
• GraphQL ist ein hervorragender Weg, Organisationsprobleme großer Tech-Unternehmen zu lösen
  • Zum Beispiel, wenn das Team, das die API wartet, nicht dasselbe ist wie das Team, das Änderungen anfordert
  • Wenn die Organisation groß ist, wartet man in so einem Fall ewig auf Änderungen, und GraphQL reduziert diese Abhängigkeit
  • Wenn die Organisation klein ist, könnte man die fehlenden Teile nicht einfach selbst ergänzen?
• Ob beabsichtigt oder nicht: GraphQL entkoppelt Frontend-Entwickler von ihren Anforderungen an Backend-Entwickler und lässt sie schneller vorankommen
  • Wenn Backend-Entwickler ein Datenmodell erstellen und es über GraphQL verfügbar machen, können Frontend-Entwickler es sofort nutzen, selbst wenn sie diese Backend-Entwickler nie getroffen haben
  • Man kann spontan ändern, was man abfragt, und genau das bekommen, was man will
  • Das bringt alle schneller voran
  • Aber ich als Backend-Entwickler hasse GraphQL wirklich

[bichi]

GraphQL ist schon ein bisschen nervig. Nicht extrem nervig, aber eben etwas nervig. Trotzdem senkt es die Kommunikationskosten im Team ganz eindeutig, deshalb ist es effizienter, die nervigen Teile in dieser Zeit zu lösen. Und ehrlich gesagt sieht es wirklich hässlich aus. Trotzdem empfehle ich, GraphQL zu verwenden. Niemand wird schließlich zustimmen, stattdessen tRPC zu nehmen. Die meisten Leute weigern sich, eine Technologie zu nutzen, oft schon aus bloßer Vorahnung, ohne sie überhaupt richtig ausprobiert zu haben. Um das zu lösen, müsste man es mit enormer Autorität durchdrücken. Bei ein oder zwei Technologien geht das vielleicht, aber wenn man alles mit Gewalt durchsetzt, verliert man am Ende mehr, also geht das nicht ... Deshalb ist GraphQL am Ende das Maximum, auf das man sich noch halbwegs einigen kann TT Dieses beschissene REST, das ist wirklich eine schlechte steinzeitliche Technologie, die enorm hohe Kommunikationskosten verursacht TT

[alucard]

Das ist der erste Beitrag auf GeekNews, wegen dem ich mich extra registriert habe. Ich habe im Abschnitt „The bad“ eine Antwort hinterlassen.

Es gibt sicher jeweils Vor- und Nachteile aus Sicht von Client und Server, aber wenn man das Gesamtbild betrachtet, ist das größte Value Proposition von GraphQL doch, dass das GraphQL-Schema die fehlende Abstraktionsschicht zwischen Server und Client füllt. Selbst wenn man das weiß, klingt die Aussage, man würde für ein gewöhnliches Produkt REST in Betracht ziehen, für mich persönlich ein bisschen wie eine Geschichte von gestern.
The bad

• It is actually a pain to use, depending on the backend you are using you'll have to manage
  two or more type systems if there are no code first generates in your language
  Am Ende heißt das mit anderen Worten doch nur: Wenn man es richtig einsetzt, ist es gut, oder? Code-Generierung und so weiter sind heute doch eigentlich kein Problem mehr. Wie sehr sich das Tooling weiterentwickelt hat.
• It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be
  some pattern where you don't want to allow this but for the majority of situations working with json api's you'll end up with a {[key: string] : T} somewhere
  Das wurde auch unter Production Ready erwähnt, aber wenn man die Vorteile des Type Systems nutzt, scheint das kein Punkt zu sein, über den man sich groß Gedanken machen müsste. Statt key: string gibt man einfach die exakten Felder an.
• No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03
  GraphQL ist von Haus aus versionlos....
  Don't use Graphql unless you're managing a solution/problem set that facebook intended graphql for Invest your time in a simpler solution then running to GraphQL first
  Das klingt für mich so, als würde man auch sagen, man solle React nicht verwenden, wenn man nicht genau die Probleme löst, die Facebook lösen wollte.

[bichi]

Hallo, gute Worte. Wäre es vielleicht möglich, in Kontakt zu bleiben? Ich brauche Leute, die ähnlich denken. Es ist viel zu schwer, andere Leute (Teammitglieder) zu überzeugen.

[alucard]

Haha, ich habe den Kommentar erst spät gesehen..!! Ich verwende im GraphQL-Korea-Slack den Nickname Alucard :)

[sixmen]

Ich habe GraphQL relativ früh eingeführt, und damals gab es viele Erklärungen, die vor allem aus der Backend-Perspektive kamen. Deshalb habe ich das Gefühl, dass es oft so wahrgenommen wird, als wäre es vor allem für das Backend etwas Gutes.

Nachdem ich mich an allerlei Dingen abgemüht habe, erkläre ich den Leuten, die später ins Unternehmen gekommen sind, oder Bewerberinnen und Bewerbern, wenn sie danach fragen, inzwischen so: Für das Backend ist es anstrengend, aber für das Frontend ist es gut. :)

[bbulbum]

#Aber als Backend-Entwickler hasse ich GraphQL wirklich
Kann ich nachvollziehen..

[ifmkl]

Da fällt mir sofort ein: auf den richtigen Einsatzort kommt es an.

[kbumsik]

Ob beabsichtigt oder nicht, GraphQL ermöglicht es Frontend-Entwicklern, sich von den Anforderungen der Backend-Entwickler zu entkoppeln und sich schneller zu bewegen.

Das ist der Grund, GraphQL zu verwenden. Auch in der GraphQL-Spezifikation steht ausdrücklich, dass es für das Frontend gedacht ist 1.
Ich habe in meinem neuen Startup ebenfalls begonnen, GraphQL zu verwenden, und ich habe definitiv das Gefühl, dass ich im Vergleich zu früher deutlich seltener mit Frontend-Ingenieuren über APIs kommunizieren muss.

Aus Sicht von Backend-Ingenieuren gibt es vor dem tatsächlichen Einsatz von GraphQL einige Probleme, an die man gar nicht gedacht hätte und die ziemlich schmerzhaft sein können, aber ich glaube trotzdem, dass es viel besser ist, als sich den Kopf darüber zu zerbrechen, wie man eine REST API gut designt.

[hwasurr]

Keine Technologie ist perfekt! Ich denke, dass sich die Einführung lohnen kann, wenn man diese Technologie wirklich braucht oder sie ein anderes, größeres Problem löst – sodass sich die Kosten zur Behebung ihrer Nachteile in Kauf nehmen lassen. Ob eine Technologie oder ein Tool geeignet ist, hängt schließlich immer von der jeweiligen Situation der Nutzenden ab.

Andererseits könnte einer der Gründe, warum GraphQL kritisiert wird, auch darin liegen, dass ihm ein Image von „einfach“ zugeschrieben wird.

[jjpark78]

Als GraphQL am Anfang aufkam und wir ein POC-Projekt durchgeführt haben, gab es keine Engine, die multipart ordentlich unterstützte, daher erinnere ich mich daran, wie mühsam das war..

[gjen6s]

Ich dachte auch schon länger, wenn man sieht, dass GraphQL in kleinen Projekten eingesetzt wird, dass das nicht viel zu überdimensioniert ist … offenbar denken viele ähnlich.

[xguru]

Ich habe vorerst nur die ersten Kommentare übersetzt. Es gibt mehr als 400 Kommentare, daher ist es schwer, sie alle überhaupt zu lesen.