Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GraphQL kinda sucks

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 448 posts

Re: GraphQL kinda sucks

#21

Post by jwr »

"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 use it because I have to (external services jumped on the hype bandwagon), but I don't consider it significant progress. And this "save bandwidth" advantage is totally oversold, I really can't see how the savings can be significant in a practical way.

Re: GraphQL kinda sucks

#22

Post by intelVISA »

legalcorrection wrote: post #16
gabereiser wrote: post #13

Earlier quoted context omitted.

In order to build a properly implemented one, one must first learn to build one. I find most people jump onto graphql because they see the volume of work to create crud endpoints for all of their models and decided to punt.

It’s a false promise. You’re just moving the complexity elsewhere, into wiring this ridiculous graphql infrastructure together and making it actually do what you want in all but the simplest/tutorial-like scenarios.

Seriously. I sometimes think I'm visiting a satirical alter realm when I see these obtuse systems that end up requiring more cognitive energy to glue together than the regular version in being praised rather than derided.

Re: GraphQL kinda sucks

#23

Post by breckenedge »

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,…

I get specialization, but are there any other good reasons to divide product teams between frontend and backend? I guess it also helps establish patterns and contracts, but I think those are only helpful above a critical mass that I haven’t reached in my career yet.

Re: GraphQL kinda sucks

#24

Post by spion »

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

Agreed. I'm working on a typed query builder for GraphQL and TS but secretly I'm a little mad that nobody gave some thought to making it easier to integrate in a type-safe way at least in the client languages

https://github.com/typed-graphql-builder/typed-graphql-build...

No docs yet, that's WIP

Re: GraphQL kinda sucks

#25

Post by quickthrower2 »

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,…

It sounds like it is promoting a siloed cogs in the machine type of work ethic. Where you are either front end or back end and no one is thinking end-to-end about the system.

Re: GraphQL kinda sucks

#26

Post by eurasiantiger »

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.

Re: GraphQL kinda sucks

#27

Post by thomassharoon »

endisneigh wrote: post #2

What exactly is the simpler solution that doesn’t result in your same cons mentioned?

There are patterns that can get you the same benefits without having to use GraphQL.

Even on a REST API, you can achieve the same pros

> - It makes working with describing the data you want easy > - It can save you bandwidth. Get what you ask for and no more

You can describe the fields you need (and I assume that is what reduces the bandwidth)

GET /users?fields=name,addresses.street,addresses.zip

> - It makes documentation for data consumers easy

I don't think so in practice. You can see Shopify's GraphQL documentation [1]. If anything it is more complex than their REST API docs

> - It can make subscription easier for you to use

Not too different from using something like SSE or even websockets and every decent web framework seems to have a decent implementation

> - Can let you federate API calls

So many ways to achieve this at the application layer (which is what GraphQL federation does with a Router). In the python world this could be separate WSGI apps or racks in ruby? And makes no difference if done at the load balancer level.

[1] https://shopify.dev/api/admin-graphql/2022-07/enums/localiza...

Re: GraphQL kinda sucks

#28

Post by geuis »

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.

Re: GraphQL kinda sucks

#29

Post by eurasiantiger »

spion wrote: post #24
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.…

Agreed. I'm working on a typed query builder for GraphQL and TS but secretly I'm a little mad that nobody gave some thought to making it easier to integrate in a type-safe way at least in the client languages https://github.com/typed-graphql-builder/typed-graphql-build... No docs yet, that's WIP

It looks like a lot more boilerplate than normal GraphQL queries.

Re: GraphQL kinda sucks

#30

Post by carapace »

First, s/opinoin/opinion/

Second, there's a reason DBA (Database Administrator, something like that) is a formal, separate role.

If you don't have a DBA it's not because that's a good idea, it's because you (or your bosses) are too cheap to do things well. That's okay, a lot of times cheap is more important than correct.

You're still going to need schema.

Both NoSQL and GraphQL seem to throw the baby out with the bath water. It was all done before, and Relational Model won. Gotta know your history kids: https://en.wikipedia.org/wiki/Database#History

- - - -

Tidbit of lore: SQL is not the original language for relational model databases, Codd had a language he called Alpha: https://en.wikipedia.org/wiki/Alpha_(programming_language)

SQL is the JS of DBs!

Post reply on HN