Comment by no_wizard
3 days ago
How was the market objectively wrong on GraphQL?
I ask a a REST turned GraphQL advocate to be clear but criticisms I hear tend to be opinions or issues with specific implementations but not ones based on the technical shortcomings of the technology
I can't comment on all the shortcomings and this may be reflective on my lack of experience with different implementations, but doesn't using GraphQL basically just enable a tonne of unoptimised database queries to occur that, at scale, could cause some serious load issues?
GraphQL says nothing about databases at all. Resolvers can get resources from anything, they’re agnostic.
None of that is inherent to the technology but it’s a common folly among developers. This is an issue with REST too but it can be more obfuscated
If a certain arrangement makes it more likely to write bad queries, and it requires extra care to write optimal queries, then it’s a worse interface to a database. I bet for really database intensive applications graphQL adds more work than it saves.
3 replies →
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".
1 reply →