Hacker News Reader

Hacker News

Comment by stickfigure | Hacker News Reader

Parent Full thread

stickfigure

> you end up making a dozen or more API calls just to show everything

This is fine!

> I've fought the urge to use graphql for years

Keep fighting the urge. Or give into it and learn the hard way? Either way you'll end up in the same place.

The UI can make multiple calls to the backend. It's fine.

Or you can make the REST calls return some relations. Also fine.

What you can't do is let the client make arbitrary queries into your database. Because somebody will eventually come along and abuse those APIs. And then you're stuck whitelisting very specific queries... which look exactly like REST.

View on HN

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.

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.

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.

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.

...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.

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".

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.

> 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.

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.

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.

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.

How is this different from REST?

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)

Generally, REST calls are narrowly tailored with a simple contract; there are some parameters in and some specific data out. This tends to be easy to secure, has consistent performance and load behavior, and shows up in monitoring tools when someone starts hammering it.

On the other hand, unless you've put some serious work into hardening, I can craft a GraphQL query to your system that will produce way more data (and way more load) than you would prefer.

A mature GraphQL web API (exposed to adversaries) ends up whitelisting queries. At which point it's no better than REST. Might as well just use REST.

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.

Reply on news.ycombinator.com