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!
Top comments (101)
Aaand... does any RESTful endpoint apply any security "by default" that's not in GraphQL?
I think your PoC (if you even did it) was not enough to cover GraphQL in detail TBH.
It's not something that exposes the entire model through an interface (which is what you think at this point reading the post).
GraphQL is just an SDL (Schema Definition Language) in which you define which properties are available in the exposed model and is you the one deciding how to resolve each property. It can be another endpoint (usually, because GraphQL shines most in Gateways), another service, a third party and so on and so forth.
If you want something by default you need to add something else to the recipe, like Apolllo for example.
you got objections in some posts not because it's an opinion out of the mainstream but because you're simply wrong for not getting into the details of the topic plus extrapolating wrong conclusions from the lack of information previously mentioned, and I'm quite sure that you know it.
If it's a marketing strategy (which I suspect true) to make people know about Aista It may be a good move (because you attract people) but also a bad move (as people can associate Aista with a bad product) I may never know the results but I'm really curious about the impact of your adventures through the community in the revenue or at least to the visitors count 😂😂
I saw a video yesterday. Its name was; “17 things you must do to secure GraphQL”. It went through everything from batch invocations, to God knows what. Using it in gateways is probably cool, but why use it in the first place then? Why not use the original API then?
As to marketing? Some other guy said the same a couple of months ago. My answer was; “I don’t have boobs” 😉
It doesn’t change the facts though. I guess people enjoy the truth … 😊
I'll be pleased to learn which are those things you need to do (and that you don't using a different stack, be a REST endpoint or whatever)
Hyperlambda is secure by default FYI …. 😉
ROFLMAO 😂
Is that an informed opinion …? 😉
This is a path you don't really want to walk, believe me. And for 3 different reasons:
First of all because claiming that "hyperlambda" is secure by default is absurd, there are different security layers in a software system and the programming language (if hyperlambda can suit in this category) isn't one of them. What makes the software secure is what you (or someone else) code and automate with those tools, not the tools itself.
Second because most people here are also in
r/programmingLastly because it's not the first time someone bring something and say "that's secure!" and then someone hacks it in few minutes or few days. First rule in security, no system is secure.
If you want to prove your thingy's secure, offer it stand-alone and let "the Internet" play with it 😉
Go for it 😊
github.com/polterguy/Magic 😂
Good luck 😉
Let the r*****s at /r/programming know I’m saying thx for all the fish 😉
Have them download it and try to hack it too in fact 😂
Oh no, that's not gonna happen. If you are going in a new crusade go ahead by your own.
From the project development point of view, checking your project seeking for vulnerabilities would be unpaid job and I don't work for free unless it's an open source project I feel necessary in the market.
By the way you shared the repo of "Magic" and since now we were talking about "Hyperlambda", where is hyperlambda?
Check out backend/files/system
Then check the 35+ plugins referenced through magic.library, referenced through NuGet. It’s not 1 project, it’s almost 40 projects. Loosely tied together using Active Events / Super Signal design patterns. It’s arguably the only non-existent Turing complete programming language, neither compiled nor interpreted, still we built our entire company on top of it.
Check it out here
Not ONE non-Hyperlambda LOC in there 😉😊💪
There’s probably 10K LOC of Hyperlambda in that repo. Why GitHub ain’t counting them you’ve got to ask them about …
I understand that hyperlambda is some syntax created by and for you, is it?
It’s a graph object model. Similar to YAML, JSON or XML. Due to how computers works, we can turn graph objects into execution trees, arguably describing everything a computer can possibly do, since fundamentally everything that’s possible to execute fundamentally can be described as a graph object. It’s got 3.5 million downloads at NuGet, and 650 stars on GutHub, so describe “for me” …
It also happens to be the only contemporary living meta programming language, facilitating for having snippets of Hyperlambda create, modify and maintain other Hyperlambda snippets. Which inevitably leads to the end of (human) software development as we know it. Hence the fish joke 😉
This is why I can give guarantees about things others cannot. Simply because I don’t create the code, the computer creates the code. I’ve been searching for “perfect code” my entire life (40+ years of development). I had to take the human out of the equation to find it 😊
It’s the ONLY programming language that produces perfect code, over and over again. And you can literally PROVE it is free from bugs because there’s no human element to it … 😉
Once we really get going, I can reproduce the ENTIRETY of GitHub’s code base in a fraction of a second, by projecting my thoughts into it using wave pattern. If AI is intelligence, Hyperlambda is “artificial life” … 😎💪
Sorry dude, we’re doing an intergalactic Al bypass here, and Earth is in our way. Do you want it in its poetry form 😅😂
Why do you explain it like it's magic?
Seriously, why do you explain it like it's magic?
ROFLMAO 😂
I’m really not. I’m explaining it as it is. You need to study it, at which point my words will make sense 🤪
To emphasize that, it’s got no syntax, zero keywords, no OO, barely any typing, and paradoxically no variables - Because everything is a variable. If you spent 5 minutes with it, all of the above would make sense. Until you do, it’ll be indistinguishable from (pun!) Magic yes …
That is the most boastful, arrogant and egoistic reply I've ever seen. Honestly, it should like some super villain declamation. Try to be humble even if you're on the internet.
Did you comment on the wrong comment or article or something? Sure, some comments here might be perceived as arrogant, although Joel can obviously handle it a assume. The comment you were commenting to didn’t have a shred of arrogance though.
Joel told a joke. I laughed and proceeded with providing factual information. How is that arrogant? I really deserve an explanation …
I think this thread should be archived and stored in a cold vault or something. It is hilarious!
Let me guess: Did you experiment with Hasura?
The #1 reason I dislike that product is it is essentially SQL-over-GraphQL, which is totally not what GQL was intended for.
As with most technologies, GraphQL has its pros and cons, but you seem to associate it with direct SQL queries, which it has nothing to do with. Try building your own GraphQL server once or at least use a public GraphQL API (like Facebook's), and you'll see.
And please don't write such emotional articles about technologies before you at least have a rough understanding of what they are.
When I speak about things I speak about how most people use it. You can use C# as a functional programming language. Most don’t though ….
As to Hasura? I have no idea about the quality of their product. But I’ll take your word for it if you think it’s garbage …
But Hasura comes with security outta the box with able to restrict visibility to parts of the schema by user creds, note it also has the ability to stitch together external GraphQL APIs and add an extra layer of security to those as well.
Might be, I've got no idea. I don't use GraphQL ...
LMAO. This explains everything.
Nobody serious about sw dev uses GQL ...
That's an inappropriate generalization. This is why you're getting so many comments accusing you of egotism and ignorance. You're speaking as if an expert in GraphQL when you haven't used it, and you're insisting that no one can possibly use it well.
Even if you feel strongly, it is never okay to insist that "serious" software developers will or will not use a particular technology.
I am not sure, but I think this is the first comment I've had accusing me of egotism? I have 2,169 reactions, 216 comments this week alone, and I'm not 100% sure, but I don't think I've seen that word before in any of my comments. So I'll take your advice, and quote you here ^_^
Except this time you are the author ... ;)
Okay. Here's a direct link to the source. If you read through these comments - you should be able to do that in under an hour - you'll see all the cases where people have expressed consternation at your ignorance and warned you that you were making claims that outstripped both your admitted expertise and your cited information.
dev.to/polterguy/graphql-is-a-hot-...
I know you really enjoy being snarky and pretending you got one over on others, but you're really just making yourself look like the goat. I've learned how to read a lot of non-verbal cues over the years. Rest assured, the flavor of snark people are using in responding to you is indicative of the fact that you have made yourself an object of humor and derision.
The word of dispute was not ignorance, it was egotism my friend ... ;)
These are two distinctly different words according to the Oxford Dictionary of English. However, I think we'll end the debate here ...
Goodbye ... :/
Do agree with some of your previous articles, don't get this one though. GraphQL is just a way to structure an API and only ask for what you need, security in my API is really easy to handle and I sure don't execute business logic on the client. Perhaps if you use one of these "hey lets expose my data model to GraphQL" things then it would have the issues you mention. I find the automatic parameter validation and the easy way to specify joins but only execute them when the client needs them means I write a lot less code.
I would say that the need to make every request be a multiline thing is the most annoying part of it compared to an RPC, but I can live with it.
That was another point I completely forgot about, how it is impossible to use REST, and turns everything into POST and PATCH. Thank you.
When I want to GET a document, I want to use the correct verb. I suspect the same is true for all wanting to build high quality software …
Not sure if it's part of the official spec, but I've implemented several graphql apis that support all the http verbs. In the client, I can pick the verb that makes the most sense. Obviously you're limited with GET requests to the url length, but when doing things like { profile { emailAddress, firstName, lastName} } you don't run the risk of hitting that limit.
Pairing this with a querystring param for the "name" of this query, my network tab starts making a lot more sense.
Something like this:
GET http://api.yoursite.com/graphql?UserProfile&q=profile{emailAddress,firstName,lastName}}
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.
I really appreciate a detailed clinical objective analysis of a technology. This isn't one of them. I wrote a GraphQL endpoint for my own universal business process engine. Security over data resources is the same whether you are using REST or GraphQL. GraphQL allows the client to define the data structure to return, but does not do an end run around security.
There are two aspects however which I think do count against GraphQL.
In order to call a GraphQL endpoint you need to discover the data structure and the relationships in order to return the data you want. Rather than supplying a URL to a resource you post something like a query. While this doesn't imply a security threat I have found this approach more difficult for front end developers. Front end developers will only end up hard coding the query, which means you are kinda pushing off query design to the front end.
It may be that some developers like the power of GraphQL, but adding yet another technology and approach may not be so welcome.
The second downside was implementation specific, so I can't say whether it is true more generally about GraphQL, and that is performance. In the Java implementation you would end up triggering query storms as it drilled down into objects. The more complex the query the harder it impacts. And the way the code worked meant you can't really optimize it.
Now I have thought of a different implementation, one where the whole query is deconstructed in order to be more efficient in terms of database queries, but this would be too much work to justify. As it happens I do like REST because in the main it works well and is reasonably simple.
No need to write a serious analysis, when you’re doing it for me 😉
Seriously, that was a great comment. If I could pin it I would. Thank you. However, I guess our conclusions are almost the same anyway. Which is encapsulated in the header of my OP …
Query storms are things I didn’t touch upon, but that I was aware of, which is a problem with most O/RM libs too …
The REST problem I’ve touched upon in other comments. HTTP has verbs for a reason. GQL turns everything into POST. Which is quite frankly absurd …
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 ... ;)
This is the most stupid article I’ve ever read 🤣
What was stupid about it?
GQL was made by the same company that was storing their users’ passwords in clear text for 2 billion users over a period of 15 years, and that was responsible for the biggest data leak through human history. Just sayin’ …
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 ...
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?
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?
LMAO
Some comments may only be visible to logged-in visitors. Sign in to view all comments.