GraphQL kinda sucks • Hacker News Board

Re: GraphQL kinda sucks

#41

Post by chpmrc » Sat, Aug 06, 2022, 2:08 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…

> Be careful with anyone with a take that says some technology is 100% bad always.

THIS 100%.

> It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring.

I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST").

After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).

Re: GraphQL kinda sucks

#42

Post by mccorrinall » Sat, Aug 06, 2022, 2:09 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…

I love consuming graphql as a client. But writing resolvers and all that stuff on the backend? God, I hate it!

Re: GraphQL kinda sucks

#43

Post by satyrnein » Sat, Aug 06, 2022, 2:09 PM UTC

quickthrower2 wrote: post #25

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.

I think the causality runs the other way. Once the frontend had gotten so complex that it required a specialized team, solutions arose to reduce the back and forth necessary between frontend and backend teams.

Re: GraphQL kinda sucks

#44

Post by chpmrc » Sat, Aug 06, 2022, 2:10 PM UTC

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.

> Graphql is a terrible piece of software/paradigm.

Says who, exactly? What data are you basing this on? Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it?

Re: GraphQL kinda sucks

#45

Post by endisneigh » Sat, Aug 06, 2022, 2:10 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…

> 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 worse from people giving things a fair try.

Completely agreed. Without knowing the team experience, greenfield project or not or in general more information about the task at hand, how can anyone say GraphQL is good or not?

One thing I've noticed among some people who've failed to move up in their career is that they carry these extreme opinions due to a proper understanding or a bad experience. Right tool for the job and all that.

Re: GraphQL kinda sucks

#46

Post by stutsmansoft » Sat, Aug 06, 2022, 2:14 PM UTC

I also had a bad experience with graphQL, or perhaps more accurately the Apollo client for it.

I hated the namespaces on the code-generated classes and ended up manually wrapping them, obviating the benefit.

It was also super brittle, when the back end would change something it would break the clients.

Re: GraphQL kinda sucks

#47

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

thomassharoon wrote: post #27

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

[deleted]

Re: GraphQL kinda sucks

#48

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

breckenedge wrote: post #23

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.

In a small organization there isn't generally any reason to divide the teams between front and back end. As you've alluded - once you have many clients you'll want to separate responsibilities in order to increase velocity.

Re: GraphQL kinda sucks

#49

Post by locutous » Sat, Aug 06, 2022, 2:15 PM UTC

quickthrower2 wrote: post #25

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.

That's generally true for sizable companies. Small companies can and do use full stack devs.

Segmentation makes some sense but the industry is lacking end to end thinking as you point out.

Re: GraphQL kinda sucks

#50

Post by lelanthran » Sat, Aug 06, 2022, 2:17 PM UTC

intelVISA wrote: post #22

legalcorrection wrote: post #16

Earlier quoted context omitted.

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.

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

You're lucky, you're only visiting. I'm working in that alternate reality :-)