3 ms·
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 wi
by 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 agoYou 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.