Remix clone Hacker News

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

▲

davzie 7 days ago | parent | next [-]

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?

▲

no_wizard 7 days ago | parent [-]

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

▲

ITB 7 days ago | parent [-]

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.

▲

no_wizard 7 days ago | parent [-]

It’s not though. Especially since GraphQL makes no mention of databases. It’s a resource agnostic protocol.

This isn’t a technical issue with GraphQL. It’s a culture issue among developers who shoehorn GraphQL and don’t use it appropriately

As someone who works on very database intense application GraphQL saves me more work than its ever caused.

▲

endofreach 3 days ago | parent | next [-]

> GraphQL makes no mention of databases. It’s a resource agnostic protocol.

So the QueryLanguage is just marketing?

▲

jayknight 7 days ago | parent | prev [-]

Any chance you can point to a good graphql implementation/framework that someone could use to learn best practices?

	▲	no_wizard 7 days ago \| parent [-]
		You're talking about the implementation of the protocol, right? That is a good implementation of it, called GraphQL Yoga[0] However I'm concerned there is a slight disconnect here. I'm saying that the technical specification of GraphQL does not lend itself to being bad, rather its the failure of developers to really understand its purpose and what its for (its a giant aggregator, with various ways to optimally aggregate things together, depending on what is optimal for a given problem set) For that, I recommend becoming more familiar with the specification itself[1] because thats what I'm talking about. The specification (and thus its technical nature) doesn't prescribe anything regarding how you get data on to the graph. Many people equate GraphQL with database problems[2] This doesn't mean I don't understand that GraphQL has shortcomings, but all approaches to APIs have short comings. I have found GraphQL has the least amount [0]: https://github.com/dotansimha/graphql-yoga [1]: https://spec.graphql.org [2]: Common complaint I see all the time. I find it stems from a failure to understand how the entirety of GraphQL is meant to work, and some of the mechanics within. Like when to appropriately leverage DataLoader[3], for instance. [3]: https://github.com/graphql/dataloader

▲

bearjaws 6 days ago | parent | prev | next [-]

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.

▲

no_wizard 5 days ago | parent [-]

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/

▲

bearjaws 5 days ago | parent [-]

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".

	▲	no_wizard 5 days ago \| parent [-]
		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.

▲

7 days ago | parent | prev [-]

[deleted]