I'll probably get objections to this one, the same way I get objections to most of my articles. If you don't believe me, check out the objections to my OOP is a software development mass psychosis article. 190+ comments, most trying to argue I'm the crazy guy. However, superstition is still superstition, regardless of how many people who believe it's the truth, and the facts are that GraphQL is a hot smoking pile of garbage, period!
First of all, GraphQL is almost the equivalent of allowing the frontend client to send SQL to the database. For crying out loud, we've got a name for that, and it's called SQL INJECTION ATTACKS. Google it if in doubt. I know it is possible to apply security to your GraphQL endpoints, by amputating half of its features. However, security is one of those things you need by default. If some piece of tech doesn't have "security by default", you don't expose it to anybody not having root access to your server infrastructure, period!
Second of all, GraphQL forces you to write business logic on the client. This implies that everyone with a Postman account can circumvent your business logic, and potentially empty your bank account, and transfer your entire holdings to their own account, in Bermuda, while publicly sharing images on Instagram that they're drinking umbrella drinks from their hammocks on the beach.
I could go on for hours further explaining why GraphQL is garbage, but really the two above points should be enough. If you're using GraphQL for anything even remotely more complex than a "hobby project", and/or sys-admin types of apps, you should carry a warning sign saying ...
I have no idea about anything related to software development
Because really, that's about the only thing GraphQL is good at. My suggestion is we "rename" GraphQL, and refer to it as what it actually is, which is the following ...
JSON based SQL insertion attacks
Because securing a GraphQL endpoint, is probably equally difficult as it is to implement a real software development solution, with business logic on the server, and validation and security on the server - Where it belongs. Exposing GraphQL endpoints to anybody but yourself, and/or the sys-admin of your app, is probably only slightly more secure than providing a text area in the public parts of your website, with a placeholder saying; "Provide SQL here ...". If you don't get it, let me type it out in code ...
<textarea placeholder="Insert SQL here ..."></textarea>
<button (onclick)="executeSql()"></button>
There's a reason why we don't do GraphQL in Aista but instead implementing our stuff in Hyperlambda, and that reason is because we don't like JSON based SQL insertion attacks.
GraphQL is a hot smoking pile of garbage, period!
Latest comments (100)
OMG…
GraphQL is nothing else but:
You could be using grpc, jsonRPC, soap, rest or whatever interface between your client and server and still have the same security issues you have with gql. Are you exposing all your API without any security ? Then "This design is a hot smoking pile of garbage, period!" but not GQL.
If you do have a DB (Dgraph, Hasura, Postgraphile, EdgeDB) you can consume using GQL, you are not supposed (unless you added proper right access or if your client is the admin) to expose this DB "as is" to your client.
the-guild.dev/graphql/mesh
We've tried such query languages a bajillion times before. HQL being one version. They always yield the same results ...
Troll marketer's playlist:
All jokes aside, this article reads like "Node.js is Cancer", and is equally ill-informed, except "Cancer" article at least had some information in it, so that it contributed to the discussion and mattered in any way.
Errh, can somebody translate please? For one, what does this have to do with NodeJS?
"Node.js is Cancer" is an industry-known article written by someone who (without understanding Node.js) tried out the technology in its infancy, trying things that you shouldn't ever do, and then whining about it not being good enough, saying that it was a cancer on the industry. You could say it was "a study" that didn't stand up to peer review.
What you have here is a reaction post, where someone is whining about a barebones API design standard not being a full-fledged product solution "because security", either from someone who isn't experienced enough to know the difference (not likely, given that you appear to have the experience) or "troll marketing" -- when someone is purposely trying to be divisive so that they can get screen time (which seems much more likely).
GraphQL assumes it is (only) about retrieving data. The idea by itself is ridiculous ... 😕
GraphQL is a query language specification. Do... do you not know that?
Yes. So was HQL. We've tried it a billion times before. It was always garbage ...
The only constant in all of your failed relationships is you.
Funny that everybody seems to agree with me on the past then ...?
OK
This article is the reason why I said a company should not let a junior dev do a tech research…🫠🫠🫠 they have limited knowledge and lack of basic understanding. this blog is straight garbage.
As long as you are dynamically querying your database, using your blahblah lamda is NOT any more secure than GQL…ultimately it’s the same. Variables goes into SQL. And this problem is solved long time ago, it’s the still the junior dev who brought this problems onboard by writing SQL manually without learning parameterized query or ORM/query builder.
It’s the same thing as REST API, there is NO such problem most of the time unless you are hand written every single SQL query in your app…
Also, if you use relay.js, they have a feature called persisted query which enables only the query you used goes into server , the user can not querying any more data than the original design.
GQL is definitely has problems, but this blog has not mentioned since the author limited experience. For example, the authorization is not straightforward as REST.
Lots of companies are adopting GQL even big techs, you’d better think your IQ is higher than all the people combined.🤣🤣🤣🤣🤣LMAO, typical junior mind set. Hard level LeetCode in 10 min without any bugs? 🤣🤣🤣🤣🤣🤣🤣🤣
Good click bait though.
No offence, but I'm probably old enough to be your father, and I started coding when computers had 32K of RAM ... ;)
O/RM is also a hot smoking pile of garbage FYI. Thx for the tip for my next article ... ^_^
Thx for the advice
Then it's even sadder that after all these years you still have no idea what the hell you're talking about, pal. Just stop embarrassing yourself.
You commenting on this thread using arguments that I am the one embarrassing myself, is actually quite embarrassing - Just sayin' ... :/
I've have seen implementions of GraphQL as you are describing them (exposing way too much data on the API and using mostly frontend logic) even in production. The developers with this habit are amateurs and prefer quantity over quality.
It doesn't make any sense to blaim the wrong usage of a technology on the technology itself though. The problems you are referring to are made by the developers, not because of using GraphQL (and the query language even has nothing to do with this problem). This would be a problem on any type of API. If I'm exposing the same data on a REST API as with a GraphQL API the same problems exists which you are referring to. If you are expecting security out of the box you are really delusional.
GraphQL is absolutely great and heavily used in a lot of enterprise applications. Many benefits exists in using GraphQL over REST especially when developing in a team.
You are referring in the comments that this is the most common way GraphQL is used (which I don't think is true). Why aren't you making this a "How you should NOT use GraphQL" article and provide better examples?
LMAO
OK, that's actually a decent idea. I'll take self criticism on some of your points (and other commenters points) - However, as to ...
And ...
Some of the fastest growing open source projects on the planet are simple wrappers around your database. It's a much larger problem than you think ... :/
If true, that is terrible indeed but then the article is targeted at the wrong concept and shouldn't be centered around GraphQL because it's a convenient tool for those database wrappers to use.
It's like blaming Firebase because some brainless developers are using Firebase's database with open access in a frontend application even though they say explicitly not to do so (a bit different, but you get the point).
Do you have examples of those database wrappers? One library I've seen that was used this was
nestjs-query.I don't even want to link to them, but there are hundreds of these service providers. One of them have 70,000+ stars on GitHub ...
That's still not a valid reason to blame the technology... Blame the developers that made the project, utilising the technology, the wrong way!
I can also create a backend with REST APIs, sending user input straight to a database without any sanitization, without autorization and authentication, etc. I can give database admin rights to users by connecting the backend to the database with bad implementation. The point is I can make an extremely vulnerable application with almost any technology that exists today, doesn't mean all of them are bad technologies.
Should we blame the company that made this door knob for how this person installed it?
That's basically you talking shit about things you don't know ¯_(ツ)_/¯
Search for "GraphQL security". One of the first hits I found was ...
There are hundreds of similar articles, and/or YouTube videos.
“I could go on for just enough time to justify some of the outlandish claims I’ve just made, but instead I’ll leave you with a half-baked mess of non-sequiturs.”
Upon cursory examination the only thing you’ve successfully communicated here is a controversial opinion lacking the force required to garner productive noise. The clickbait served here is sure to attract attention through sensationalism but has no chance of inspiring truly meaningful conversation about the technology in question.
I think some of the comments here are fairly deep and meaningful. I don't agree with them, but they've definitely done their job ...
troll content, this would be better in medium
Do a search for "GraphQL security". There are hundreds of documented security issues around GraphQL.
Well I think you need to explore GraphQL a little bit deeper. In my opinion it has many advantages over REST endpoints.
One of them is how easy is for frontend and backend devs to have a better communication over their endpoints, the GraphQL playground is super helpful, even more than tools like swagger.
I have worked with a few big companies that use GraphQL at a large and very secure scale. Apollo is also super helpful when connecting apps to GraphQL.
I mean Facebook created it and still uses it, and they are doing great.
Facebook stored their users' passwords in cleartext the first 15 years they operated, and they are responsible for the largest data breach through human history. I've got tons of friends who have had their Facebook accounts hacked, multiple times (non-IT savvy people, but still). I don't think you should take security advice from Facebook ... ;)
GraphQL is the wrong solution to the wrong problem - Kind of like CORS ...
My mistake, I was talking about Meta as a company (WhatsApp, instagram, Facebook)
I forgot to mention that GraphQL is just the face of the backend, all the security and logic lives there and GraphQL just connects you with those controllers.
No, you don't write your business logic in the frontend with graphql...
No, you don't have a secured REST API out of the box, so there is no difference to GraphQL... You also have to implement rate limits, deep nesting limits, batch limits to REST APIs...
No, a GraphQL query is not a type of SQL injection :D there are some approaches for these things (like Prisma) but this is not the reason, why GraphQL was invented...
GraphQL is a query language, you can use it for mutations (put, post,patch), it does a quite good job at automatically validate (and with directives also sanitize) inputs... Which you also have to implement on your REST endpoints... So there is also no difference to the "good" old stuff...
GraphQL is not the perfect match for every task, that's for sure, but it's a good common query language for the frontend, and a nice abstraction for your data model...
You have to secure ANY API... So, if you don't secure your REST APIs, you have a problem... Also if you don't secure your GraphQL resolvers... Easy like that
Let me see if I've got this correctly understood; Basically, what you're saying, is that GraphQL doesn't do anything, right? I cannot query my database, and I cannot choose from my client which entities I want it to return, what joins and "includes" I want to retrieve, and if I want it, I need to apply security to everything anyways in my backend, right ...?
You realise you just reduced GraphQL to nothing, right ...? ;)
So which is it ...?
And how does that explain Hasura that somebody else commented about in this article?
:D no, i haven't reduced GraphQL to nothing... GraphQL with it's query schema has many benefits.
You can easily make virtual fields to your query fields,
you can query deep nested fields, without the need to write a deep query filter yourself ( which you have to do with any REST implementation)
you can implement security at that place, where it is needed, so if you want to have a secured "email" field, you can write your securing logic in the email field resolver...
but let me ask you the other way around.... everything you mentioned is also true to any other API standard, right? :D
GraphQL is just a better query standard than any REST filter parameter logic... it's just more descriptive, which is always a good choice, when it comes to team development... the frontend guy/gal has a nice documentation (if introspection is on), the schema of the backend is clear and straight forward, there are no questions.... when you want to make it in REST... have fun, documenting every field, with every endpoint with every nested response object... :D
Psst ...
The above project is one of their primary use cases. They've got 35,000 stars on GitHub. There's another company twice as large as Hasura, having 70,000 stars on GitHub, self proclaimed as "the fastest growing open source project on the planet".
According to a website called "Alternatives to" (something), these two companies have respectively 90 and 50 alternatives, doing "similar things".
If I'd guess, I'd say that 95% of those using GraphQL is using it similarly to the above architectural sketch, implying they've got business logic in the client, and building queries in the frontend - Just sayin' ... ;)
psst... i hope you know, that fast growing things are not always the best things... there are so many examples, where fast growing techs has much faster dissappeared, than they grewed... of course, you are building queries in the frontend, or by the way, on the edge.... cause you are not forced to expose your queries to the frontend code, there are so many tools like SSR and edge computing, so the browser does not need to know anything about your queries... this is not so different to the traditional way, we used before... but it's more practical, when the code is where it's needed...
just sayin' :D
Word! Tell that to the 98% of GQL users constructing GQL queries in JavaScript ... ;)
Hi I'm this guy, I make uninformed, sweeping unpopular statements to get people to react. My happiness is dependent on the amount of ppl that respond. Feed me.
I am trying to apply cognitive dissonance into an echo chamber. You should try it some time. It tends to result in cognitive revisions, allowing alternative and sometimes better ideas to surface ... ;)
You can't build a building without tearing down whatever was there from before if the land is already occupied. Today the "land of software development" has been occupied, mostly by garbage ideas, hence here we are ...
This you? dev.to/dncrews/comment/218ie
Is it relevant?
Man just post this on Twitter as a "hot take" you'll get more engagement. (That is what your goal is after all)
Sure, I am guilty of wanting to evangelise our stuff. That doesn't imply I don't care about code quality and good architecture. I've got 25+ years as a professional enterprise software developer. During most of those years, I was the guy who was "sent in to salvage things once it went south" - At which point I had to figure out how to salvage a project that was so badly architected and implemented it resulted in physical pain in my body simply looking at its code.
I started Aista and Magic for one simple reason, which was that I wanted to eliminate bad code from the surface of the Earth. If you've got some tips and tricks as to how to facilitate for that even better than what I'm currently doing, I would love to hear you out ;)
I don't think you realise it or not but graphql APIs can be built on top of existing REST APIs with the business logic on either of them; It's called a middleware, which is supported in both express and Apollo graphql (with the context object).
And for the point of security, you'd do everything in graphql the same as in a REST API, for example creating only an endpoint to get a user's info by their id (yes, that is supported in gql resolvers). Also, Never expose a sensitive data endpoint(like a password hash entry in the db) in the schema, or rest API and keep that data to the server just for the auth middleware.
Idk if you read the documentation or do your research but you didn't even present your points in a 'presetable' manner. You just dumped your opinion in your article with some arbitrary code without even mentioning the existence of Apollo graphql, nest js or typegraphql.
And my last point is that you assume everyone is using SQL databases without knowing there's a thing called 'SQL injection'. I use mongoDB with mongoose ODM, and it works fine for the most part. So where's the insert SQL injection here... for me?
These are good points, and I don't disagree. However, when I see how most people are actually using GQL, they're using it as a replacement of SQL. The "largest open source project on the planet" (according to its maintainer) is nothing but a GraphQL wrapper on top of PostgreSQL. There are 88 similar projects to this project according to a site that keeps track of alternatives, and I know about at least a handful of companies having been given between 20 and 150 million dollars in VC funding to setup a GQL2SQL wrapper as a hosting solution.
Every single comment here being critical towards my OP aren't wrong, they only fail to see how the thing is being used by most people. You can use C# as a functional programming language. I would know, since we built Magic that way. However, it is an OOP language at its core, and most people are using it as an OO tool.
When I write articles, I am trying to make people understand things that I've seen as problems in my 25+ years as an enterprise software developer. My reasons is because I've maintained too many garbage projects being forced to fix bugs in projects built on a garbage architectural foundation, and I feel I have a moral obligation to teaching people to stay away from such anti patterns resulting in garbage code. In order to achieve that, I must sometimes generalise beyond the point where it make sense for everybody. All my articles needs to be read with that fact in mind ...
How do one mute this guy out of my feeds?
I just don't find him worth considering, he claims "OOPs is psychosis", and the only proof he presents again and again is OOP code can be lengthy, completely disregarding modularity and abstractions.
Click on my profile and block me.
Thanx, done.
Cheers.
The world most traffic websites like Facebook, Twitter, GitHub are using GraphQL. The article itself just a garbage.
Most people don’t use GQL the same way these sites are using it. They’re using GQL as an excuse to not create server side code, and are exposing their database directly to the client, such that they can create their business logic in JavaScript, in the frontend …
Then your article should've been titled "Don't use GQL as an excuse to not create server side code" and you should've tried to make that (very) specific point. Your arguments aren't against GraphQL per se, they are against a specific usage of GraphQL which you perceive to be prevelant.
OK, good point. It's the way most people are using GQL though ...
Much to Arad's point, I'd even question your copious use of the term "most". Have you actually examined the majority of GraphQL instances in production? If so, can you link to some statistics, both to help prove your point, and to provide additional insight for discussion?
It's tempting to make claims about majority and minority, but in fact, one cannot honestly make such claims without fairly rigorous process.
Phrases you should use instead:
The "fastest growing open source project on the planet" does this, among other things. They've got 70,000 stars on GitHub. I don't want to link to them for these reasons to be honest with you. Another FOSS project with 40,000+ stars is doing it. They are vaguely mentioned in the comments here if you want to do your own research ...
If you don't think I'm correct, the burden to prove me wrong is on your side of the table, not mine ...
Nope, the burden is actually on you, author. You're the one making the claims, and inappropriately broad ones at that.
I also doubt you've done a proper technical examination of how GraphQL is used in most of those thousands of projects. If you don't have the time to examine the majority of them, you don't have the authority to write an article on how "most people" use GraphQL.
If you cannot disproof my claim, I prefer it my way. Besides, what's the big fuss anyways? If I'm wrong, everybody using GQL would know, right ...? ;)
The big fuss is that you're repeatedly crossing the line of the Code of Conduct. Particularly:
You've been incredibly rude and dismissive of other experiences...especially experiences WITH GraphQL, which you've admitted you don't have.
I really doubt that you've integrated GraphQL into one of your projects because you've mentioned a lot about security and data exposing.
(1) For reasons of security
GraphQL is not a query language like SQL that directly queries your DB. It's just a layer or transformer of your API to make frontend and mobile developers' lives easier. All security stuff (SQL injection, data validation, etc.) should be done with your API. It's not related to GraphQL.
And people are using GraphQL in many ways; it's not always for a dashboard like Aista. For instance, SSG tools like Gatsby and Gridsome provide a GraphQL API.
How would you hack into it? It does generate pure HTML and CSS.
(2) Data disclosure
It's nonsense to hack publicly shared data like blogs and web information.
And no real-world GraphQL API would share database credentials.
GQL is being "sold" as an alternative to REST, because it allows people to "query their database". If you're using it in a sane way, I congratulate you. Most people aren't using it that way ...
Some comments may only be visible to logged-in visitors. Sign in to view all comments.