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!
GraphQL is a hot smoking pile of garbage
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 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!