GraphQL is a hot smoking pile of garbage(aista.com)
aista.com
GraphQL is a hot smoking pile of garbage
https://aista.com/blog/graphql-is-hot-smoking-pile-of-garbage/
22 comments
I don't think this author has much experience with GraphQL.
Your typical "POST Body" in GraphQL is strong typed the same way as the response body.
You also don't have to (and I'd say you shouldn't) map your SQL database to your GraphQL schema 1 to 1.
In my experience, databases like Firebase are more likely to be susceptible to these attacks given their hard to understand permission models.
Your typical "POST Body" in GraphQL is strong typed the same way as the response body.
You also don't have to (and I'd say you shouldn't) map your SQL database to your GraphQL schema 1 to 1.
In my experience, databases like Firebase are more likely to be susceptible to these attacks given their hard to understand permission models.
> You also don't have to (and I'd say you shouldn't) map your SQL database to your GraphQL schema 1 to 1.
My main complaint about GraphQL is that junior engineers tend to use it as an excuse to do exactly that. They don't understand that the API and database schema are different things.
My main complaint about GraphQL is that junior engineers tend to use it as an excuse to do exactly that. They don't understand that the API and database schema are different things.
How is that a complaint about GraphQL when the common alternative, REST, was basically designed to map 1:1 API resources to database tables. Each endpoint is a resource, and every resource is almost always either most of a table or a simple table join.
1. graphql absolutely does not open you up to sql injection attacks. You could certainly end up being trapped by a endless recursive call loop but there are ways to clip your tree to avoid that!
2. graphql does not force your business logic to the client. you write a mutation. it takes parameters. whatever goes on after that is in the server and is whatever you want ON THE SERVER.
disclaimer: I built my startup on graphql.
Their hyperlambda product seems interesting but the number of things they get flat out wrong about sql makes me question if they did their homework before trying to make something better.
2. graphql does not force your business logic to the client. you write a mutation. it takes parameters. whatever goes on after that is in the server and is whatever you want ON THE SERVER.
disclaimer: I built my startup on graphql.
Their hyperlambda product seems interesting but the number of things they get flat out wrong about sql makes me question if they did their homework before trying to make something better.
I have been working daily with GraphQL for 6 years and have no idea what the author is talking about. And I cannot find a single thing sustaining his claim in the article.
There are difficulties with GraphQL such as limiting n+1 requests while also having complex db level permissions. But I really don’t see how sql injections would happen more often than with classic rest.
There are difficulties with GraphQL such as limiting n+1 requests while also having complex db level permissions. But I really don’t see how sql injections would happen more often than with classic rest.
This is hilarious; I don't think I've ever encountered trolling that goes this deep. Beyond this GraphQL post, the other blog articles are even funnier -- and then there's the github repo and its fake issues.... brilliant!
[deleted]
GraphQL is a great way for letting apps and people query data in _the way you intended it to be queried_.
SQL injection is about querying and change data in ways _that were not intended_.
This article is comparing apples to oranges. If you're using this articles logic, any kind of dynamic queries are SQL INJECTION.
The article also assumes that GraphQL = no security, which is not a general assumption you can make, and, which you could also apply to any other technology.
SQL injection is about querying and change data in ways _that were not intended_.
This article is comparing apples to oranges. If you're using this articles logic, any kind of dynamic queries are SQL INJECTION.
The article also assumes that GraphQL = no security, which is not a general assumption you can make, and, which you could also apply to any other technology.
> Second of all, GraphQL forces you to write business logic on the client.
Yes. I may very well have goals that imply pulling some data and doing client-side work that is inappropiate for upstream.
Picking where/when to do work is sometimes referred to as 'engineering'.
Yes. I may very well have goals that imply pulling some data and doing client-side work that is inappropiate for upstream.
Picking where/when to do work is sometimes referred to as 'engineering'.
It sucks to set up Graphql but once you’ve got it going it’s pretty cool from the dev making the request perspective
I was kind of excited when I saw the headline, because I am currently going through a bit of graphql fatigue. But, wow, this is a majorly misinformed person. I generally love the clickbait style, but you cannot be entirely clueless or it just becomes obvious the dunning kruger effect is at play which is whats happening here.
My advice to the author is delete this immediately and go learn graphql.
My advice to the author is delete this immediately and go learn graphql.
no strong opinion either way here, but would have liked to see a bit more technical depth here beyond the allegations of sql injection and a click baity title.
Someone finally said it!
Without sustaining any claims.
I agree with you. However claim itself is not far off
Could you elaborate? The claim is so different from my experience that I am really curious as to why.
The grounds cited are drivel. There are other reasons one can dislike GraphQL, but the ones cited in the article are strictly nonsense.
I sencond the motion
GraphQL is a specification, it doesn't imply an implementation.
A GraphQL "resolver" is identical to the concept of an "endpoint", you have no idea what the business logic inside of an endpoint is. That's up to the implementer.
No API specification I am aware of comes with "security by default", again, that's an implementation detail?
It's to you to add AuthZ/AuthN to your REST/RPC/GQL etc API, by themselves the handlers are just dumb networked functions.
I really don't have anything to say on this.
I guess the implication is that you have somehow exposed your entire database with zero access controls via GraphQL and don't know how to write resolvers?
In that case, I'm more concerned for your employer than your angst against GQL, lol.