5 ms·

To me, the question is the other way round because the advantages (pointed out by all the other comments in this thread so I won't repeat) are clear, kind of im

To me, the question is the other way round because the advantages (pointed out by all the other comments in this thread so I won't repeat) are clear, kind of immediately. It's the disadvantages, particularly the 'unknown unknowns' that I wonder about, and that's what's kept me from using it. GraphQL so far seems like the archetypal counter example for the 'use boring stuff' philosophy of software engineering. I kind of hope I'm wrong here, because the advantages are big and pretty cool.

strken 7y ago
GraphQL is pretty boring, at least on the server. You give your GraphQL library a schema and tell it how to deal with fields, and then it makes a tree of fields from your query and populates them according to your instructions. It can get "exciting" on the client, particularly with libraries like Apollo. See for example the bug https://github.com/apollographql/apollo-client/issues/1186 https://github.com/apollographql/apollo-client/issues/1186, which took two years to fix. The tooling for persisted queries can also be hard to set up, and they're close to required if you want to expose GraphQL to your client.
- dmitriid 7y ago
  It’s actually exciting on the server. Ad-hoc queries with unlimited complexity? Check. No caching? Check. No auth? Check.
  - barbellguy97 7y ago
    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
    - 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.
  - strken 7y ago
    The solution to ad-hoc queries is to not use ad-hoc queries. Persisted queries are becoming common. Caching is no harder in GraphQL than it is anywhere else. You define resolvers; if you want to put stuff in Redis, you're free to do so. Auth is also no harder in GraphQL than it is anywhere else. You have complete control over what happens in a resolver, which includes authorising access and throwing an error/returning null/etc.
    - davnicwil 7y ago
      To dig in on the persisted queries thing, which I mentioned in a reply to the sibling comment, have you seen practical advantages doing this vs just doing a plain old RPC style http API? It seems to just move all the flexibility of GraphQL to dev time, and makes it only useful for a private API where you control both the client and the server. This is all fine, but then I just don't see why you'd move away from a classic API where caching is free for GETs and you don't have to go through the abstraction of GraphQL schemas and resolvers etc to do your endpoint logic, you can just do it. One thing I could possibly see is that client side libraries like Apollo etc bring huge advantages like free client caching or other things I'm not aware of - is that the case?
      - strken 7y ago
        At the company which used GraphQL in production, two of the major reasons for adoption were decoupling the backend from the UI of the client, and allowing front-end developers to easily update the payload without making changes to the server, which weren't affected by using persisted queries. Caching was handled by separate backend services rather than the graphql service or the client, which wouldn't make sense for every usecase. Apollo was really useful for managing state across the client. Tools like optimistic updates were very nice too. Unfortunately, it was somewhat buggy when we were using it, and the API kept changing, but I think it's more stable now. It was also good to have a well-defined schema between client and backend, although you should have one anyway.
        davnicwil 7y ago
        Yeah, that makes sense. I think the usecase I'm optimising for is solo and/or full stack engineers in a relatively small team where everyone is free to do everything. When that's the case, obviously these kinds of abstractions may just get in the way rather than help. I've worked for companies in the past that had the organisational setup you describe, however, where frontend engineers didn't even have pull access to the code for api services they were talking to, where this would have been a massive advantage in terms of productivity. I seem to end up at this conclusion in most discussions about GraphQL, usually with facebook scale being referenced, where it seems that as a technology its main advantages might actually be architectural in terms of the organisation of how massive systems are engineered, by huge numbers of people. The temptation is always to jump in and compare the technical merits and specifics, and overlook this, but I'm coming more to the opinion that this is the answer here to when to use GraphQL over REST / RPC over http. That is, at the scale of a massive engineering organisation, it might be an abstraction whose advantages outweigh the downsides, but probably not if you're a small team.

strken 7y ago

GraphQL is pretty boring, at least on the server. You give your GraphQL library a schema and tell it how to deal with fields, and then it makes a tree of fields from your query and populates them according to your instructions. It can get "exciting" on the client, particularly with libraries like Apollo. See for example the bug https://github.com/apollographql/apollo-client/issues/1186 https://github.com/apollographql/apollo-client/issues/1186, which took two years to fix. The tooling for persisted queries can also be hard to set up, and they're close to required if you want to expose GraphQL to your client.

dmitriid 7y ago
It’s actually exciting on the server. Ad-hoc queries with unlimited complexity? Check. No caching? Check. No auth? Check.
- barbellguy97 7y ago
  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
  - 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.
- strken 7y ago
  The solution to ad-hoc queries is to not use ad-hoc queries. Persisted queries are becoming common. Caching is no harder in GraphQL than it is anywhere else. You define resolvers; if you want to put stuff in Redis, you're free to do so. Auth is also no harder in GraphQL than it is anywhere else. You have complete control over what happens in a resolver, which includes authorising access and throwing an error/returning null/etc.
  - davnicwil 7y ago
    To dig in on the persisted queries thing, which I mentioned in a reply to the sibling comment, have you seen practical advantages doing this vs just doing a plain old RPC style http API? It seems to just move all the flexibility of GraphQL to dev time, and makes it only useful for a private API where you control both the client and the server. This is all fine, but then I just don't see why you'd move away from a classic API where caching is free for GETs and you don't have to go through the abstraction of GraphQL schemas and resolvers etc to do your endpoint logic, you can just do it. One thing I could possibly see is that client side libraries like Apollo etc bring huge advantages like free client caching or other things I'm not aware of - is that the case?
    - strken 7y ago
      At the company which used GraphQL in production, two of the major reasons for adoption were decoupling the backend from the UI of the client, and allowing front-end developers to easily update the payload without making changes to the server, which weren't affected by using persisted queries. Caching was handled by separate backend services rather than the graphql service or the client, which wouldn't make sense for every usecase. Apollo was really useful for managing state across the client. Tools like optimistic updates were very nice too. Unfortunately, it was somewhat buggy when we were using it, and the API kept changing, but I think it's more stable now. It was also good to have a well-defined schema between client and backend, although you should have one anyway.
      - davnicwil 7y ago
        Yeah, that makes sense. I think the usecase I'm optimising for is solo and/or full stack engineers in a relatively small team where everyone is free to do everything. When that's the case, obviously these kinds of abstractions may just get in the way rather than help. I've worked for companies in the past that had the organisational setup you describe, however, where frontend engineers didn't even have pull access to the code for api services they were talking to, where this would have been a massive advantage in terms of productivity. I seem to end up at this conclusion in most discussions about GraphQL, usually with facebook scale being referenced, where it seems that as a technology its main advantages might actually be architectural in terms of the organisation of how massive systems are engineered, by huge numbers of people. The temptation is always to jump in and compare the technical merits and specifics, and overlook this, but I'm coming more to the opinion that this is the answer here to when to use GraphQL over REST / RPC over http. That is, at the scale of a massive engineering organisation, it might be an abstraction whose advantages outweigh the downsides, but probably not if you're a small team.