3 ms·

> any problem you attribute to graphql, will exist in rest. Every single one and more. And then you go on to say: > fine-tune any ad-hoc query REST doesn't h

> any problem you attribute to graphql, will exist in rest. Every single one and more. And then you go on to say: > fine-tune any ad-hoc query REST doesn't have ad-hoc queries, so no, this problem doesn't exists in REST > it’s much harder to design good resolvers, queries and limits So, it's much harder than in REST, but somehow REST has the same problems. Riiiight. > After all, if you have problems quering complex nested data (and you really objectively need it on a front end) in graphql, it can be only harder to handle correctly in rest, please, please prove me wrong. Once again: in REST you know exactly what your query will be. And even if it's hard to query and retrieve nested data, you can optimise that retrieval for that specific REST request you provide. With me so far? GraphQL allows ad-hoc queries of unbounded complexity. This is the one and most significant problem that REST doesn't have. With me so far? So, given all that, and given that you'r saying "it's much harder to design good resolvers, queries and limits" in GraphQL, how is handling complex data harder to handle correctly in REST?

lyxsus 6y ago
It is not unbounded, unless you let it. Once again, at query time you have the full query. It’s not infinitely recursive. And if you split fetching the data by multiple endpoints and pretend your job is done, basically delegating the problem to your clients, what else can I say?
- dmitriid 6y ago
  > It is not unbounded, unless you let it. It is unbounded by default. And the tool you're so enamoured with, postgraphie, even has a dedicated section on this: https://www.graphile.org/postgraphile/production/ https://www.graphile.org/postgraphile/production/ Let me quote: "Due to the nature of GraphQL it's easy to construct a small query that could be very expensive for the server to run". And lo, and behold, it doesn't really have a solution against it. So you have to either revert to basically REST with a predefined number of whitelisted queries, or pay for an experimental extension that attempts to calculate the cost of query. > And if you split fetching the data by multiple endpoints and pretend your job is done, basically delegating the problem to your clients, what else can I say? You can say something that actually shows that you know what you're talking about. Because you clearly have very little knowledge about REST and very sparse knowledge about GraphQL. You don't even know that unbounded complexity and infinite recursion are inherent in GraphQL.
  - lyxsus 6y ago
    Show me an example of how you make an infinite recursive query in graphql, I’ll wait. And I can spell it to you again, you know structure and complexity of your query before you execute it. Feel free to ignore it and disguise ignorance behind I’ve pointed out by reverting that back on me. I’m asking a pretty simple questions, while you’re deflecting with an assumption that I need to prove my worth of your time, lol I rarely engage in online discussions and only if know for sure what I’m saying.
    - dmitriid 6y ago
      > Show me an example of how you make an infinite recursive query in graphql, I’ll wait. Literally in the example provided by postgraphile. It literally shows how to DDOS a GraphQL service by constructing a simple recursive query. It literally shows how even a few levels of recursion will break your server. It literally shows that by default GraphQL - and postgraphile - has nothing against this. So yes, you can increase recursion in the query ad infinitum, which is my point that you fail to understand. > Feel free to ignore it and disguise ignorance behind I’ve pointed out by reverting that back on me. Stop projecting. You can't even understand what the tool you mentioned does, and the problem the tool's own documentation describes. Adieu.
      - BenjieGillam 6y ago
        [PostGraphile author here, and I wrote that page of documentation.] Firstly, GraphQL does not allow for infinite recursion; it is literally not possible to do infinite recursion in GraphQL; the GraphQL spec even has a section on this: https://spec.graphql.org/draft/#sec-Fragment-spreads-must-not-form-cycles https://spec.graphql.org/draft/#sec-Fragment-spreads-must-no... Secondly, it's extremely easy to add a GraphQL validation rule that limits the depth of queries; here's an example of one where it takes just a single line of code: https://github.com/stems/graphql-depth-limit https://github.com/stems/graphql-depth-limit . This isn't included by default because there are plenty of solutions you're free to choose between, many of which are open source, depending on your project's needs. For most GraphQL APIs, persisted queries/persisted operations is the tool of choice, and is what Facebook have used internally since before GraphQL was open sourced in 2015. (Unlike what you state, this does not turn your API into a "REST API," it acts as an optimisation on the network layer and once configured is virtually invisible to client and server.)

lyxsus 6y ago

It is not unbounded, unless you let it. Once again, at query time you have the full query. It’s not infinitely recursive. And if you split fetching the data by multiple endpoints and pretend your job is done, basically delegating the problem to your clients, what else can I say?

dmitriid 6y ago
> It is not unbounded, unless you let it. It is unbounded by default. And the tool you're so enamoured with, postgraphie, even has a dedicated section on this: https://www.graphile.org/postgraphile/production/ https://www.graphile.org/postgraphile/production/ Let me quote: "Due to the nature of GraphQL it's easy to construct a small query that could be very expensive for the server to run". And lo, and behold, it doesn't really have a solution against it. So you have to either revert to basically REST with a predefined number of whitelisted queries, or pay for an experimental extension that attempts to calculate the cost of query. > And if you split fetching the data by multiple endpoints and pretend your job is done, basically delegating the problem to your clients, what else can I say? You can say something that actually shows that you know what you're talking about. Because you clearly have very little knowledge about REST and very sparse knowledge about GraphQL. You don't even know that unbounded complexity and infinite recursion are inherent in GraphQL.
- lyxsus 6y ago
  Show me an example of how you make an infinite recursive query in graphql, I’ll wait. And I can spell it to you again, you know structure and complexity of your query before you execute it. Feel free to ignore it and disguise ignorance behind I’ve pointed out by reverting that back on me. I’m asking a pretty simple questions, while you’re deflecting with an assumption that I need to prove my worth of your time, lol I rarely engage in online discussions and only if know for sure what I’m saying.
  - dmitriid 6y ago
    > Show me an example of how you make an infinite recursive query in graphql, I’ll wait. Literally in the example provided by postgraphile. It literally shows how to DDOS a GraphQL service by constructing a simple recursive query. It literally shows how even a few levels of recursion will break your server. It literally shows that by default GraphQL - and postgraphile - has nothing against this. So yes, you can increase recursion in the query ad infinitum, which is my point that you fail to understand. > Feel free to ignore it and disguise ignorance behind I’ve pointed out by reverting that back on me. Stop projecting. You can't even understand what the tool you mentioned does, and the problem the tool's own documentation describes. Adieu.
    - BenjieGillam 6y ago
      [PostGraphile author here, and I wrote that page of documentation.] Firstly, GraphQL does not allow for infinite recursion; it is literally not possible to do infinite recursion in GraphQL; the GraphQL spec even has a section on this: https://spec.graphql.org/draft/#sec-Fragment-spreads-must-not-form-cycles https://spec.graphql.org/draft/#sec-Fragment-spreads-must-no... Secondly, it's extremely easy to add a GraphQL validation rule that limits the depth of queries; here's an example of one where it takes just a single line of code: https://github.com/stems/graphql-depth-limit https://github.com/stems/graphql-depth-limit . This isn't included by default because there are plenty of solutions you're free to choose between, many of which are open source, depending on your project's needs. For most GraphQL APIs, persisted queries/persisted operations is the tool of choice, and is what Facebook have used internally since before GraphQL was open sourced in 2015. (Unlike what you state, this does not turn your API into a "REST API," it acts as an optimisation on the network layer and once configured is virtually invisible to client and server.)