3 ms·

GraphQL is not arbitrary queries into your database! Folks need to really quit misunderstanding that. You can define any schema and relations you want, it's n

by gedy 2y ago

GraphQL is not arbitrary queries into your database! Folks need to really quit misunderstanding that. You can define any schema and relations you want, it's not an ORM.

stickfigure 2y ago
In the spectrum of "remote procedure call" on one end and "insert sql here" on the other end, GraphQL is waaaaay closer to SQL than RPC.
- ako 2y ago
  No it’s not, graphql is an rpc that returns a tree of objects where you can indicate what part of the tree is relevant to you.
  - stickfigure 2y ago
    ...and that's exactly the problem! Without a lot of hardening, I (a hostile client) can suck down any part of the database you make available. With just a few calls. GraphQL is too powerful and too flexible to offer to an untrusted party.
    - gedy 2y ago
      This is a silly argument and sounds like a hot take from someone who's never used this. You could say the same about REST or whatever. It has nothing to do with "the database".
      - stickfigure 2y ago
        You sound like someone that's never had an adversarial client. I spent years reverse engineering other companies' web APIs. I'm also responsible for a system that processes 11 figures of financial transactions, part of which (for now) is an incredibly annoying GraphQL API that gets abused regularly. REST calls are fairly narrowly tailored, return specific information, and it's generally easy to notice when someone is abusing them. "More like RPC". Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time. Take a look at Shopify's GraphQL API to see the measures you need to take to harden an API; rate limits defined by the number of nodes returned, convoluted structures to handle cursoring. GraphQL is the kind of thing that appeals to frontend folks because they can rebalance logic towards the frontend and away from the backend. It's generally a bad idea.
      - gedy 2y ago
        > Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time No it won't, because it's not tied directly to the database and does not allow for arbitrary queries. Any of the "aha!" gotchas you mention are the same issues as you could have with REST, JSON-API, etc. I'm sorry you don't understand what I'm pointing out, but thanks for the convo though.
  - whstl 2y ago
    Yep. It is not trivial to make it into a pseudo-SQL language, like Hasura did. Funny enough, see this assumption frustrating a lot of people who try to implement GraphQL APIs like this. And even if you do turn it into a pseudo-SQL, there's still plenty of control. Libraries allow you to restrict depth, restrict number of backend queries, have a cost function, etc.
what 2y ago
It is arbitrary queries though? I can send any query that matches your schema and your graphql engine is probably going to produce some gnarly stuff to satisfy those queries.
- whstl 2y ago
  You need to program every query resolver yourself, it's not tied to some ORM. There are of course products that do this automatically, but it's not really that simple. There's a reason things like Hasura are individual products.
- gedy 2y ago
  No when I say "schema" I mean the GraphQL structure, not your DB schema. The GraphQL structure can be totally independent from your DB if need be, and (GraphQL) queries on those types via API can resolve however you need and are defined by you. It's not a SQL generator.
  - stickfigure 2y ago
    The problem is not that you'll expose some part of the database you shouldn't (which is a concern but it's solvable). The problem is that you expose the ability for a hostile client to easily suck down vast swaths of the part of the database you do expose.
    - foobazgt 2y ago
      How is this different from REST?
      - gedy 2y ago
        I think the OP is possibly confusing GraphQL with an ORM like Active Record. You are correct that you don't accidentally "expose" any more data than you do with REST or some other APIs. It's just a routing and payload convention. GraphQL schema and types don't have to be 1:1 with your DB or ActiveRecord objects at all. (I'm not aware of any, but if there are actually gems or libraries that do expose your DB to GraphQL this way, that's not really a GraphQL issue)

by gedy 2y ago

GraphQL is not arbitrary queries into your database! Folks need to really quit misunderstanding that. You can define any schema and relations you want, it's not an ORM.

stickfigure 2y ago

In the spectrum of "remote procedure call" on one end and "insert sql here" on the other end, GraphQL is waaaaay closer to SQL than RPC.

ako 2y ago
No it’s not, graphql is an rpc that returns a tree of objects where you can indicate what part of the tree is relevant to you.
- stickfigure 2y ago
  ...and that's exactly the problem! Without a lot of hardening, I (a hostile client) can suck down any part of the database you make available. With just a few calls. GraphQL is too powerful and too flexible to offer to an untrusted party.
  - gedy 2y ago
    This is a silly argument and sounds like a hot take from someone who's never used this. You could say the same about REST or whatever. It has nothing to do with "the database".
    - stickfigure 2y ago
      You sound like someone that's never had an adversarial client. I spent years reverse engineering other companies' web APIs. I'm also responsible for a system that processes 11 figures of financial transactions, part of which (for now) is an incredibly annoying GraphQL API that gets abused regularly. REST calls are fairly narrowly tailored, return specific information, and it's generally easy to notice when someone is abusing them. "More like RPC". Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time. Take a look at Shopify's GraphQL API to see the measures you need to take to harden an API; rate limits defined by the number of nodes returned, convoluted structures to handle cursoring. GraphQL is the kind of thing that appeals to frontend folks because they can rebalance logic towards the frontend and away from the backend. It's generally a bad idea.
    - gedy 2y ago
      > Your naive GraphQL API, on the other hand, will let me query large chunks of your database at a time No it won't, because it's not tied directly to the database and does not allow for arbitrary queries. Any of the "aha!" gotchas you mention are the same issues as you could have with REST, JSON-API, etc. I'm sorry you don't understand what I'm pointing out, but thanks for the convo though.
- whstl 2y ago
  Yep. It is not trivial to make it into a pseudo-SQL language, like Hasura did. Funny enough, see this assumption frustrating a lot of people who try to implement GraphQL APIs like this. And even if you do turn it into a pseudo-SQL, there's still plenty of control. Libraries allow you to restrict depth, restrict number of backend queries, have a cost function, etc.

what 2y ago

It is arbitrary queries though? I can send any query that matches your schema and your graphql engine is probably going to produce some gnarly stuff to satisfy those queries.

whstl 2y ago
You need to program every query resolver yourself, it's not tied to some ORM. There are of course products that do this automatically, but it's not really that simple. There's a reason things like Hasura are individual products.
gedy 2y ago
No when I say "schema" I mean the GraphQL structure, not your DB schema. The GraphQL structure can be totally independent from your DB if need be, and (GraphQL) queries on those types via API can resolve however you need and are defined by you. It's not a SQL generator.
- stickfigure 2y ago
  The problem is not that you'll expose some part of the database you shouldn't (which is a concern but it's solvable). The problem is that you expose the ability for a hostile client to easily suck down vast swaths of the part of the database you do expose.
  - foobazgt 2y ago
    How is this different from REST?
    - gedy 2y ago
      I think the OP is possibly confusing GraphQL with an ORM like Active Record. You are correct that you don't accidentally "expose" any more data than you do with REST or some other APIs. It's just a routing and payload convention. GraphQL schema and types don't have to be 1:1 with your DB or ActiveRecord objects at all. (I'm not aware of any, but if there are actually gems or libraries that do expose your DB to GraphQL this way, that's not really a GraphQL issue)