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 t...
For further actions, you may consider blocking this person and/or reporting abuse
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
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
Before creating such an editor, one should think about what is being created. It was better to use the Apollo client instead. Doesn't the developer even have enough time to update it?
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' ... :/
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.
Looks like someone who hasn't built anything with GraphQL on production, might have used some ready-made solution for GQL (like Hasura) and using GraphQL as clickbait to attract people to his own project.
As I told some other guy here. Iβve never used Hasura, but if you think itβs garbage Iβll take your word for it β¦
troll content, this would be better in medium
Do a search for "GraphQL security". There are hundreds of documented security issues around GraphQL.
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?
β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 ...
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 ...
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 ;)
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 ...
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.