3 ms·

Hmm. From what I understand of GraphQL, it gives you: - less boilerplate (no need to create GET REST endpoints and corresponding JS AJAX calls) - consequently

Hmm. From what I understand of GraphQL, it gives you: - less boilerplate (no need to create GET REST endpoints and corresponding JS AJAX calls) - consequently, more flexibility (just request more data in the client, no need to update server code) - formalized query language (and apparently, the ability to check it?) However, the idea of exposing your schema to arbitrary requests sounds much too dangerous to me. I see the advantages for really large applications, but I'll stick to REST with a 'format' parameter for the foreseeable future.

RussianCow 11y ago
This seems to be a common misconception. GraphQL is just a protocol; query fields don't have to be tied to your schema at all, so you don't have to expose anything you don't want to, in the same way that you don't have to make every table accessible via REST.
- mercurial 11y ago
  Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.
  - andrewingram 11y ago
    This is actually solvable. The queries that will be executed by an app can be analysed statically, and therefore are available as part of a build pipeline. So it's possible to create a whitelist of queries automatically, or even go one step further and give each query a short unique ID and just say "execute query foo with these parameters" rather than sending the actual body of the query over the network.
    - mercurial 11y ago
      Yeah, but at that point the quantity of magic will start to make me uncomfortable.
    - aikah 11y ago
      When a solution requires this kind of hacks for a simple task as rate limiting, maybe the solution is a bad one to begin with. With REST it is fairly easy to do rate limiting on endpoints. With GraphQL, it is fairly easy to DDOS with a complex query that will ask the server to fetch an insanely complex data structure. And there are no endpoints anymore.
- deleted 11y ago
  [deleted]
- kodablah 11y ago
  While it doesn't have to be tied to your schema, it provides too much flexibility. I worked on an API that provided a data graph-type of way to fetch desired data. The problem quickly became that we were not able to predict the exact paths provided which made it very difficult to tailor the performance. We didn't realize this early, but as the API usage grew, we realized the flexibility was a mistake. The article mentions pre-processing the graph to determine complexity, some caching, and some timeouts. This is not good enough and can/will be worked around. Inflexible API's with (mostly) single, predictable paths to data provide a great way to tailor performance at the (IMO) negligible cost of extra HTTP requests.

RussianCow 11y ago

This seems to be a common misconception. GraphQL is just a protocol; query fields don't have to be tied to your schema at all, so you don't have to expose anything you don't want to, in the same way that you don't have to make every table accessible via REST.

mercurial 11y ago
Let me rephrase that: you are exposing a way to trivially traverse the entire object graph you're exposing through the API, putting you at risk of DOSing your server when your friend Joe the frontend dev makes a small mistake in his query. You can obviously get the same result with REST, but usually you have to work a lot harder for it.
- andrewingram 11y ago
  This is actually solvable. The queries that will be executed by an app can be analysed statically, and therefore are available as part of a build pipeline. So it's possible to create a whitelist of queries automatically, or even go one step further and give each query a short unique ID and just say "execute query foo with these parameters" rather than sending the actual body of the query over the network.
  - mercurial 11y ago
    Yeah, but at that point the quantity of magic will start to make me uncomfortable.
  - aikah 11y ago
    When a solution requires this kind of hacks for a simple task as rate limiting, maybe the solution is a bad one to begin with. With REST it is fairly easy to do rate limiting on endpoints. With GraphQL, it is fairly easy to DDOS with a complex query that will ask the server to fetch an insanely complex data structure. And there are no endpoints anymore.
deleted 11y ago
[deleted]
kodablah 11y ago
While it doesn't have to be tied to your schema, it provides too much flexibility. I worked on an API that provided a data graph-type of way to fetch desired data. The problem quickly became that we were not able to predict the exact paths provided which made it very difficult to tailor the performance. We didn't realize this early, but as the API usage grew, we realized the flexibility was a mistake. The article mentions pre-processing the graph to determine complexity, some caching, and some timeouts. This is not good enough and can/will be worked around. Inflexible API's with (mostly) single, predictable paths to data provide a great way to tailor performance at the (IMO) negligible cost of extra HTTP requests.