Comment by no_wizard
2 days ago
All of these are developer issues and not issues with the technology. They aren’t inherent to GraphQL.
By your own admission it’s sloppy developer work that causes issues it’s not the tech.
REST APIs actually do have an inherent problem, which is they’re one call == one source. Everything has to be bespoke to the endpoint, where as GraphQL as a technology allows one to not have to do that.
Versioning APIs is a code smell. With GraphQL you can combine queries by using Fragments for example. You could also perform concurrent resolution with resolvers and merge data results if if it’s appropriate for the scenario to resolve a single query. There is far more flexibility in the model but you as a developer are 100% in charge of performance and such, no different than REST. GraphQL gives far more flexibility in finding a solution for any given scenario, where as REST is an extremely rigid 1 == 1 resource coupling.
As for pagination isn’t built into REST. Anything “standard” about that was bolted on and varies quite a lot. Where as GraphQL does address this[0] on an implementation reference level.
Regarding exposing schema, while I question if there is the security risk you're implying it to be (lots of organizations expose their GraphQL schemas, like Salesforce and GitHub) but never the less, any good implementation will have a single line option for turning it off. Apollo does (arguably the most popular of the implementations) but so does GraphQL Yoga and even implementations in other languages.
As far as developers go, the biggest mistake developers make is creating schema that is simply a clone of their database schema at the end of the day, and this is the absolute worst way to go about implementing GraphQL. Its explicit purpose is to have a middle layer that lets you express APIs for intended purpose, not to be coupled to your database schema
All problems with all software are developer issues. Technically, we could do everything in Assembly, but we don't.
Ideally, a technology needs to solve as many problems as possible while introducing as few problems as possible. That is why I am not sure every organization should use GraphQL.
If someone came to me from an SMB and asked "should we switch to GraphQL" I would first ask what problems they have, and what they believe GraphQL will solve. Then make an informed decision, the answer is not "yes, you should always use GraphQL".
That wasn't the question as posed though. It was 'regarding its technical basis, what issue does GraphQL have?' and rarely do I ever get an actual technical problem with how graphql is structured.
REST has at least 1 inherent flaw in its model, which is 1-1 API resource coupling.
Now, if we want to talk about perhaps skill threshold? Yeah, GraphQL requires a higher level of confidence and experience to use correctly.