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?
Why aren't you making this a "How you should NOT use GraphQL"
OK, that's actually a decent idea. I'll take self criticism on some of your points (and other commenters points) - However, as to ...
I've have seen implementions of GraphQL as you are describing them
And ...
The problems you are referring to are made by the developers, not because of using GraphQL
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.
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?
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
