4 ms·

Some other bad things: - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A h

Some other bad things: - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource. It's not like in REST where the request tells you exactly and precisely what resource the client wants to access. - Adds overhead on the server side. It requires additional resources to process a query rather than just fetching resources by ID or fetching simple lists of resources. A lot of work may need to happen behind the scenes to fulfill a query and GraphQL hides this from the developer; this can lead to inefficient queries being used. I have a similar complaint about database ORMs which generate complex queries behind the scenes; this makes it difficult to identify performance issues in the underlying queries (since these are often completely hidden from the developer). Hiding necessary complexity is not a good idea... Maybe worse than adding unnecessary complexity.

endisneigh 4y ago
> - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. You could use something like https://stellate.co/ https://stellate.co/. > - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource. Hasura and Postgraphile can do this - in the case of Postgraphile it obviously requires Postgres.
- the_mitsuhiko 4y ago
  If the solution for caching problems turns out to be a hosted API proxy then there are still not enough tools available. If you put some third party infrastructure in front of your API then your availability is exactly that company's availability.
krschultz 4y ago
It shifts the complexity to the server side. The additional logic you are describing currently lives on the client, where it's harder to update and likely duplicative across platforms.
ojkelly 4y ago
You can cache the objects in the query by ID. And then reuse them across a number of queries. > It's not like in REST where the request tells you exactly and precisely what resource the client wants to access. It can be. You can have a query that does `getObject(id: $id): Object`. > Adds overhead on the server side. Yep it pulls a heap of complexity around data fetching, synchronisation, and data modelling from the client to the server. As it requires both the client and server to come to some agreement about a shared data model, it can appear as more work up front. But it enables a decoupling of the client and server such that the client can make requests for new use cases with the existing shared data model.

endisneigh 4y ago

> - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. You could use something like https://stellate.co/ https://stellate.co/. > - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource. Hasura and Postgraphile can do this - in the case of Postgraphile it obviously requires Postgres.

the_mitsuhiko 4y ago
If the solution for caching problems turns out to be a hosted API proxy then there are still not enough tools available. If you put some third party infrastructure in front of your API then your availability is exactly that company's availability.

krschultz 4y ago

It shifts the complexity to the server side. The additional logic you are describing currently lives on the client, where it's harder to update and likely duplicative across platforms.

ojkelly 4y ago

You can cache the objects in the query by ID. And then reuse them across a number of queries. > It's not like in REST where the request tells you exactly and precisely what resource the client wants to access. It can be. You can have a query that does `getObject(id: $id): Object`. > Adds overhead on the server side. Yep it pulls a heap of complexity around data fetching, synchronisation, and data modelling from the client to the server. As it requires both the client and server to come to some agreement about a shared data model, it can appear as more work up front. But it enables a decoupling of the client and server such that the client can make requests for new use cases with the existing shared data model.