GraphQL kinda sucks • Hacker News Board

Re: GraphQL kinda sucks

#71

Post by lofatdairy » Sat, Aug 06, 2022, 2:44 PM UTC

From what I've read GraphQL makes the most sense in the context of large scale teams and large databases. It introduces a large amount of overhead to your backend to parse queries, but allows those queries to be more flexible and not think about the database's schema which is a tremendous boon when you get to the scale where communication between teams is more expensive than implementation time. For junior and midlevel devs watching youtubes and reading blogs it's obviously an exciting technology because of what it promises (in this sense GraphQL is hardly unique), but there's a practical cost to production workloads.

That said, if I'm not mistaken GraphQL is almost explicitly designed with a versionless paradigm in mind. Whether or not that's a good decision is up for debate, but it's less "no clear path" and more like it's the responsibility of the backend to add support for new access patterns without causing old patterns to fail.

Re: GraphQL kinda sucks

#72

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

gabereiser wrote: post #12

I tried graphql in a microservices environment and had huge headaches over schema stitching. Turns out, if you have lots of objects from disparate sources, graphql don’t like that. Now you must stitch these schemas together into an über schema roll query and use with graphql. Maybe we missed a step. Maybe we misunderstood. Maybe it was a bad decision.

I used graphql at one place and our stitching was a disaster. I'm thinking bad decision.

We also had micro services. It was the most unstable backend I've ever worked with.

Yet the architects who picked all these techs were mostly lauded and didn't stick around to deal with the mess.

Re: GraphQL kinda sucks

#73

Post by mabbo » Sat, Aug 06, 2022, 2:47 PM UTC

grumple wrote: post #61

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

Honestly it's mostly just lack of familiarity, which is getting better every day.

Re: GraphQL kinda sucks

#74

Post by hn_user145 » Sat, Aug 06, 2022, 2:49 PM UTC

In any fast paced business, APIs constantly change. Versioning is not straightforward. Often corners are cut, and deadlines have to be met. There just is one version of the API, the one in production!

In my experience the most pain around GraphQL was due to a lack of care/time. Too often schemas are not strictly defined, are too generic (type: any) and fields are not documented. Errors are poorly defined etc. Combine that with untyped code, it's almost the same as sending blobs of arbitrary JSON around. In the short term it works, the feature is live, business is happy. But takes double the effort to untangle the code when you need to change something....

GraphQL also requires effort to make tooling and monitoring work well with it as it deviates from a traditional REST like model.

Re: GraphQL kinda sucks

#75

Post by anotherhue » Sat, Aug 06, 2022, 2:49 PM UTC

Comparing GQL to REST is like comparing a framework to a protocol. Of course it's easier to build up from REST, but if you're lucky enough that your project survives it won't be long before you're reimplementing the same GQL features you rubbished in a half-arsed way.

In an ideal world, we can grow into the tech pulling in features as needed, but REST (in its modern form) is all about day 1 productivity, not day 100.

Re: GraphQL kinda sucks

#76

Post by mLuby » Sat, Aug 06, 2022, 2:51 PM UTC

Having worked in big tech and small startups, I think GraphQL is a brilliant way to solve an organizational problem that massive tech companies have.

It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to add the work to their roadmap and get back to it in a few quarters. Relevant Krazam: https://www.youtube.com/watch?v=y8OnoxKotPQ

At a small start-up, if the GET /foo/:fooId/bar/ endpoint is missing a field baz you need, you can usually just add it yourself and move on.

Re: GraphQL kinda sucks

#77

Post by samarthr1 » Sat, Aug 06, 2022, 2:52 PM UTC

mark_and_sweep wrote: post #34

legalcorrection wrote: post #11

Ignore all the noise and just use an RPC model between your backend and frontend. All these stupid trends and overengineered abstractions will come and go, but people will still be using plain RPC in 5, 10, 100, and 1000 years.

But before you use RPC, try rendering your markup on the server. That, too, reduces a lot of complexity.

At cost of reducing cache ability though no?

It is cheaper for me to put my react app in front of a cdn, split out my app into an api and front end than for me to have my site be entirely uncacheable.

I can also cache certain endpoints behind the cdn that are mostly invariant for users. And, the network egress of json is much lesser than the egress of markup.

Re: GraphQL kinda sucks

#78

Post by anotherhue » Sat, Aug 06, 2022, 2:52 PM UTC

endisneigh wrote: post #40

geysersam wrote: post #6

Earlier quoted context omitted.

Just make a perfect api without any drawbacks.

GraphQl has a set of trade-offs. REST also has trade-offs. Bespoke RPC calls have trade offs. It's as if the entire discipline is an exercise in selecting trade offs or something.

Well put. Problem is we can get emotionally invested and tie our identities to these systems in a way that we couldn't if we were comparing the trade-offs between 18/10 and 18/12 inox steel.

Re: GraphQL kinda sucks

#79

Post by syastrov » Sat, Aug 06, 2022, 2:52 PM UTC

grumple wrote: post #61

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

e.g. postgraphile

Re: GraphQL kinda sucks

#80

Post by yellow_lead » Sat, Aug 06, 2022, 2:53 PM UTC

hn_user145 wrote: post #74

In any fast paced business, APIs constantly change. Versioning is not straightforward. Often corners are cut, and deadlines have to be met. There just is one version of the API, the one in production! In my experience the most pain around GraphQL was due to a lack of care/time. Too often schemas are not strictly defined, are too generic (type: any) and fields are not documented. Errors are poorly defined etc. Combine…

> There just is one version of the API, the one in production!

Unless there are multiple in production, i.e /v1/api, /v2/api, etc