GraphQL kinda sucks • Hacker News Board

Re: GraphQL kinda sucks

#61

Post by grumple » Sat, Aug 06, 2022, 2:27 PM UTC

mabbo wrote: post #18

Whether it was the intention or not, I find GraphQL solved a fascinating problem: it let front end developers move faster by greatly decoupling their data needs from the backend developers. Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly,…

Curious as to why you hate it specifically. Because what you could be doing is exposing every table / field automatically based on permissions (which you could set up a system where you don't even have to be involved).

Re: GraphQL kinda sucks

#62

Post by [deleted] » Sat, Aug 06, 2022, 2:28 PM UTC

eurasiantiger wrote: post #26

jwr wrote: post #21

"Very Senior Dev" here (though it amuses me to call myself that). I had managed to avoid GraphQL for a while, but recently had to actually look at it and use it. I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.…

Hmm, there’s really nothing preventing you from writing a library which allows you to pass a data skeleton to an async function and get a full body back.

[deleted]

Re: GraphQL kinda sucks

#63

Post by spion » Sat, Aug 06, 2022, 2:31 PM UTC

chpmrc wrote: post #36

jwr wrote: post #21

"Very Senior Dev" here (though it amuses me to call myself that). I had managed to avoid GraphQL for a while, but recently had to actually look at it and use it. I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.…

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…

The GP is right. GraphQL is especially annoying because it looks so close to JS/JSON, yet since no thought was put into how it might integrate into existing typed languages its actually surprisingly difficult to build a type-safe API around it.

And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At least with SQL we have a reasonably good way to model it with methods (see LINQ). LINQ was built 15 years ago, so this problem was well understood back then.

Re: GraphQL kinda sucks

#64

Post by jongjong » Sat, Aug 06, 2022, 2:33 PM UTC

Some other bad things:

- Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries.

- Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource. It's not like in REST where the request tells you exactly and precisely what resource the client wants to access.

- Adds overhead on the server side. It requires additional resources to process a query rather than just fetching resources by ID or fetching simple lists of resources. A lot of work may need to happen behind the scenes to fulfill a query and GraphQL hides this from the developer; this can lead to inefficient queries being used. I have a similar complaint about database ORMs which generate complex queries behind the scenes; this makes it difficult to identify performance issues in the underlying queries (since these are often completely hidden from the developer). Hiding necessary complexity is not a good idea... Maybe worse than adding unnecessary complexity.

Re: GraphQL kinda sucks

#65

Post by noname120 » Sat, Aug 06, 2022, 2:34 PM UTC

Add the fact that the cache performance is unpredictable and inconsistent.

GraphQL queries select specific fields for “performance reasons” so each request is custom and you can't cache at the edge. This is ridiculous because SQL joins are costly but fetching a few extra textual fields is basically never a bottleneck.

So in order to save a few bytes or KBs (which nobody care about anyway), you ruin your caching abilities...

...Well unless you manually cache your GraphQL queries with more fields than needed but then what's the point of using GraphQL at all?

That's very often a terrible compromise.

Re: GraphQL kinda sucks

#66

Post by lf-non » Sat, Aug 06, 2022, 2:36 PM UTC

thdxr wrote: post #35

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache norma…

Agree with everything here, but something that often gets missed is that you don't have to use all that GraphQL enables from day one.

It is perfectly fine to start with an early implementation that treats GraphQL as mostly an RPC, with only resolvers for Query & Mutation types. You still benefit from GraphQL's type-safety, batching and code-generation.

Once you have more familiarity with dataloaders, query complexity etc. update your output objects to have links to other output objects building the graph model.

The issue is that too many people get fascinated with GraphQL early, then build deep & complex topologies and expose it in inefficient and potentially insecure way.

Re: GraphQL kinda sucks

#67

Post by thdxr » Sat, Aug 06, 2022, 2:37 PM UTC

meesterdude wrote: post #57

thdxr wrote: post #35

Be careful with anyone with a take that says some technology is 100% bad always. Given enough experience / skill you can make any technology fairly enjoyable so I've only ever seen mixed reactions at worst from people giving things a fair try. GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache norma…

> Given enough experience / skill you can make any technology fairly enjoyable Have you never used MongoDB?

https://twitter.com/thdxr/status/1394903426023272452?t=BjMUo...

Re: GraphQL kinda sucks

#68

Post by jddil » Sat, Aug 06, 2022, 2:39 PM UTC

I'm glad the tide seems to be turning against GraphQL.

Your company is not Facebook, you don't have an impossibly large graph dataset that needs querying

I've used it 3 times, each time it was a nightmare. REST with some additional params to query extra data is so much easier and safer ... that's just not very cool I guess.

Re: GraphQL kinda sucks

#69

Post by endisneigh » Sat, Aug 06, 2022, 2:39 PM UTC

jongjong wrote: post #64

Some other bad things: - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries. - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved i…

> - Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries.

You could use something like https://stellate.co/.

> - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource.

Hasura and Postgraphile can do this - in the case of Postgraphile it obviously requires Postgres.

Re: GraphQL kinda sucks

#70

Post by cudgy » Sat, Aug 06, 2022, 2:42 PM UTC

hn_throwaway_99 wrote: post #60

geuis wrote: post #28

It's not an unpopular opinion: it's true. Graphql is a terrible piece of software/paradigm. I've completely avoided it for years. If a potential new job contacts me and they use graphql, it's an immediate no from me. It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Run away, as fast as possible.

> It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in. Well, at least I'm glad I know I'll never be working with you! I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment. Whenever I see a comment from any developer that says "If yo…

You are right that this arrogant attitude is juvenile, but it is prevalent amongst humans in all areas. Unfortunately, there would be few developers to work with if you apply the policy of not working with arrogant, dogmatic developers.