5 ms·

What do you mean wirh unlimited complexity, no caching oe aithorization? Have you ever used ot server-sody? Because they are all solved problems, except maybe c

What do you mean wirh unlimited complexity, no caching oe aithorization? Have you ever used ot server-sody? Because they are all solved problems, except maybe caching in the transport layer, depensing on which forn of caching you're targetting.

dmitriid 7y ago
> What do you mean wirh unlimited complexity, no caching oe aithorization? I mean what I mean exactly. - GraphQL allows ad-hoc queries of unlimited complexity. - Since it's POST requests, there's no caching on the HTTP layer. - Since it's add-hoc queries, it's hard to devise a cache for the DB layer. - There are no easy solutions for either authentication or authorisation for queries (and subqueries and/or fields) > Because they are all solved problems If by solved you mean "busily reinventing the wheel and adding layers and layers of unneeded complexity, and it will only work if you buy into a single vendor's solution such as Apollo". For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached.
- Aeolun 7y ago
  > For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached. That sounds exactly the same as the thing you do when caching a HTTP request to me..? Whether the fields are in the request body or the query string is pretty much irrelevant. I think you are just annoyed that they misappropriated HTTP to do it.
  - deleted 7y ago
    [deleted]
  - dmitriid 7y ago
    > That sounds exactly the same as the thing you do when caching a HTTP request to me..? ETag, Is-Modified-Since, Last-Modified, Cache-Control don't require any parsing of the request body. And the relevance is huge. It's one thing to match a resource id in a URL in an idempotent cacheable request. It's another to have request body fully parsed by a caching middleware layer in a non-idempotent non-cacheable request. > I think you are just annoyed that they misappropriated HTTP to do it. They looked at HTTP and threw out everything HTTP already has built in. And all the tools.
    - Aeolun 7y ago
      > It's another to have request body fully parsed by a caching middleware layer in a non-idempotent non-cacheable request. As far as I understand it you can use the request body directly as a caching key. No need to parse it. If you request exactly the same thing there’s no need to re-request it.
      - dmitriid 7y ago
        That would be a way to do it, but that would require the client to send exact queries. Depending on how queries are constructed, that will not always be the case. Also, a quick look at the top search query for “Apollo graphql caching” shows that Apollo needs to deconsteuct the object (both for the request and the response) to be able to cache things: https://www.apollographql.com/docs/react/advanced/caching/ https://www.apollographql.com/docs/react/advanced/caching/ (I’m using Apollo here as one of the most advanced GraphQL solutions)
davnicwil 7y ago
What are the generally accepted solutions to these problems? Can you point to any sources? They're probably the big 3 that have stopped me from using GraphQL so far. Only thing I'm currently aware of that might 'solve' arbitrary complexity and caching is limiting queries to pre-approved whitelisted ones the server knows about and references with an id, which is more of a workaround than a solution, and removes the main advantages for whole sets of usecases like open apis for 3rd party use.
- Ralfp 7y ago
  Unlimited query complexity: - graphql() function takes "validators" argument for a reason ;) There are multiple strategies for limiting complexity, but common ones are boxing (limiting depth and width of query) or query cost limitation. For auth, you authenticate user using custom middleware before entering the query executor. Inside query executor you can do one of many things, depending on what makes sense for you: error field resolution, return "null", or return custom type like "ObjectNotFoundError". For caching, you cache inside resolvers that do something costful, or in data loaders those resolvers call.
  - davnicwil 7y ago
    Thanks for this reply! Are things like query depth, width and cost limiting available as parameters to common libraries? On the auth thing, one thing I commonly do with REST is have a general 'is this user authenticated' middleware and then later have a 'permissions' middleware that checks if the user has rights to see/modify the thing they are trying to, but that's at the service level for that particular thing. Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on?
    - Ralfp 7y ago
      > Are things like query depth, width and cost limiting available as parameters to common libraries? No, they are mostly 3rd party utils. I those exist for Apollo server. > Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on? Yes. Or I would move auth check up a level, and implement schema directive like "@authenticated" or "@hasPerm("perm")" so resolver would do only data resolution, but each approach has advantages and downsides.

dmitriid 7y ago

> What do you mean wirh unlimited complexity, no caching oe aithorization? I mean what I mean exactly. - GraphQL allows ad-hoc queries of unlimited complexity. - Since it's POST requests, there's no caching on the HTTP layer. - Since it's add-hoc queries, it's hard to devise a cache for the DB layer. - There are no easy solutions for either authentication or authorisation for queries (and subqueries and/or fields) > Because they are all solved problems If by solved you mean "busily reinventing the wheel and adding layers and layers of unneeded complexity, and it will only work if you buy into a single vendor's solution such as Apollo". For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached.

Aeolun 7y ago
> For crying out loud, one of the "solutions" for caching is to actually parse both the incoming and the outgoing requests, read the fields and decide if it needs to be cached. That sounds exactly the same as the thing you do when caching a HTTP request to me..? Whether the fields are in the request body or the query string is pretty much irrelevant. I think you are just annoyed that they misappropriated HTTP to do it.
- deleted 7y ago
  [deleted]
- dmitriid 7y ago
  > That sounds exactly the same as the thing you do when caching a HTTP request to me..? ETag, Is-Modified-Since, Last-Modified, Cache-Control don't require any parsing of the request body. And the relevance is huge. It's one thing to match a resource id in a URL in an idempotent cacheable request. It's another to have request body fully parsed by a caching middleware layer in a non-idempotent non-cacheable request. > I think you are just annoyed that they misappropriated HTTP to do it. They looked at HTTP and threw out everything HTTP already has built in. And all the tools.
  - Aeolun 7y ago
    > It's another to have request body fully parsed by a caching middleware layer in a non-idempotent non-cacheable request. As far as I understand it you can use the request body directly as a caching key. No need to parse it. If you request exactly the same thing there’s no need to re-request it.
    - dmitriid 7y ago
      That would be a way to do it, but that would require the client to send exact queries. Depending on how queries are constructed, that will not always be the case. Also, a quick look at the top search query for “Apollo graphql caching” shows that Apollo needs to deconsteuct the object (both for the request and the response) to be able to cache things: https://www.apollographql.com/docs/react/advanced/caching/ https://www.apollographql.com/docs/react/advanced/caching/ (I’m using Apollo here as one of the most advanced GraphQL solutions)

davnicwil 7y ago

What are the generally accepted solutions to these problems? Can you point to any sources? They're probably the big 3 that have stopped me from using GraphQL so far. Only thing I'm currently aware of that might 'solve' arbitrary complexity and caching is limiting queries to pre-approved whitelisted ones the server knows about and references with an id, which is more of a workaround than a solution, and removes the main advantages for whole sets of usecases like open apis for 3rd party use.

Ralfp 7y ago
Unlimited query complexity: - graphql() function takes "validators" argument for a reason ;) There are multiple strategies for limiting complexity, but common ones are boxing (limiting depth and width of query) or query cost limitation. For auth, you authenticate user using custom middleware before entering the query executor. Inside query executor you can do one of many things, depending on what makes sense for you: error field resolution, return "null", or return custom type like "ObjectNotFoundError". For caching, you cache inside resolvers that do something costful, or in data loaders those resolvers call.
- davnicwil 7y ago
  Thanks for this reply! Are things like query depth, width and cost limiting available as parameters to common libraries? On the auth thing, one thing I commonly do with REST is have a general 'is this user authenticated' middleware and then later have a 'permissions' middleware that checks if the user has rights to see/modify the thing they are trying to, but that's at the service level for that particular thing. Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on?
  - Ralfp 7y ago
    > Are things like query depth, width and cost limiting available as parameters to common libraries? No, they are mostly 3rd party utils. I those exist for Apollo server. > Would you follow a similar strategy in GraphQL? Generic auth in a middleware for a user, then specific access management auth inside specific resolvers later on? Yes. Or I would move auth check up a level, and implement schema directive like "@authenticated" or "@hasPerm("perm")" so resolver would do only data resolution, but each approach has advantages and downsides.