Comment by bearjaws
3 days ago
GraphQL has too many foot guns for your typical SMB to implement successfully, especially pivoting from REST. It requires you to architect your solution much further ahead than most companies have the capability to.
I prefer it over SOAP, but I think it's far too easy to ignore:
N+1 issues
Security (found that we had our entire schema open including internal data routes at my last job), also we had to refactor from patients being company -> patient to company -> pharmacy -> patient... that was fun
Overcomplicating resolvers
Not implementing pagination upfront
Dead end schema designs, since you need to plan much further ahead it really hurts when you mess it up. In REST you can make a V2 of a route and move on. Especially since many people ignore modules at first. Even large corporations get stuck with UserEntity_V2, updateUser_V2.
IMO if you are going "wow if only we had GraphQL" and your team only knows REST you are always better off improving your REST tooling and standards. For example, when adding a new entity/resource you can just plan to understand how your own teams intend to query for this data, rather than guessing with GraphQL or implementing every search pattern.
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
[0]: https://graphql.org/learn/pagination/
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.