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

261–270 of 448 posts

Re: GraphQL kinda sucks

#261

Post by sibeliuss »

sonthonax wrote: post #241

GraphQL seems to be one of those 'bootcamp technologies'. I see it being advertised as a skill a bootcamp teaches more than I've ever seen used. I can imagine that for a junior developer the endless freedom might be quite paralysising. What I don't understand about GraphQL, is that the majority of data people deal with is simple and relational. It's rare enough to have a deep (more than 4 layers) relational data stru…

With GraphQL you are making a view of your data. You're using types to describe an idealized API response. It's a frontend and it can do anything you want.

Re: GraphQL kinda sucks

#262

Post by loosescrews »

aleclm wrote: post #218

We recently had to design an HTTP API, and we wanted to have as much automatic stuff as possible. I mean: * Autogenerated documentation * Autogenerated wrappers for scripting languages * Autogenerated validator for requests and responses For a REST API, you can get most of these things with swagger or stuff like that, but clearly it's an afterthought. If you have a schema, it's all much more natural and elegant. But…

> But the most important thing you get with GraphQL is batching.

Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing.

Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using).

Re: GraphQL kinda sucks

#263

Post by wizofaus »

chrisweekly wrote: post #56

IME GraphQL is kinda great on the consuming side, but the complexity and maintenance overhead of query resolvers can outweigh the benefits. I agree that it makes sense to look elsewhere first. For example, react-query can solve many of the problems GraphQL aims to solve (eg overfetching), without the downsides.

Can you expand on that? If your existing RESTish/JSON Api doesn't support the level of fine tuning of what data you want back, how can react-query prevent overfetching? I ask because I'm currently involved in converting some code over to react-query, despite the fact there's a longer term plan to move to GraphQL which I'm concerned will obviate the need for the current rewrite.

Re: GraphQL kinda sucks

#264

Post by makeitdouble »

no_wizard wrote: post #186
makeitdouble wrote: post #179

Earlier quoted context omitted.

I used to see GraphQL (and to an uglier respect Soap like interfaces) as complicated solutions to that problem you describe. But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture. Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info t…

Do you have any reference material for the Yahoo architecture?

It was pretty basic so I’m not sure how much it was talked outside of Yahoo. I see this presentation http://www.radwin.org/michael/talks/php-at-yahoo-zend2005.pd... providing an overview, but otherwise the basic principle was to have each addressable web server host an apache with a routing module, and that module will map a request path to a cgi file.

With that structure you can have any number of layers with your front call and the different business abstractions all representated by an API (let’s say you want a user’s average engagement with a service, you’d hit the high level API, which will fetch access stats from another API, which rely on a lower level API which goes through another separate layer managing DB cache etc.

Most of these call are of course internal to a data center.

Re: GraphQL kinda sucks

#265

Post by minusf »

eduction wrote: post #109
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 isn’t that though; the first sentence starts “GraphQL is great, but” and then the post lists first “the good” and then “the bad.” Even the provocative headline hedges with “kinda.” I wish there was more of this sort of balanced discussion on HN. There is a tendency among devs at least in public toward trying to get others to use t…

> balanced discussion

while the discussion can be balanced the real world outcome is normally binary: use it or drop it.

i will not start investing huge amounts of time to learn graphql if it has very specific use cases for specific environments. so i naturally look for red flags and objectively negative experiences to see if those might be the roadblocks i would run into 2 months down the line.

imagine a PM coming in all happy "i know nothing about graphql besides the hype but i think it's a great fit for our next project". where will balanced discussion take you there?

Re: GraphQL kinda sucks

#266

Post by spywaregorilla »

hn_throwaway_99 wrote: post #141
spywaregorilla wrote: post #126

Earlier quoted context omitted.

I felt pretty confident about my conclusions of my first dusty old bank job that used a custom shittier homebrew of google web toolkit and no source control.

But that's very different. "No source control" means they aren't following or don't understand the very basics of software process management. That's very different from "If you use SCM system X, Y or Z you're an idiot."

Email and the windows file system is a SCM system if you're dumb enough.

Re: GraphQL kinda sucks

#268

Post by yetanotherloser »

Always sad at wasted effort but something here feels odd to me. Use graph technologies if you genuinely have a graph problem; use graph technologies if you have an "almost tree but..." problem; don't use graph technologies if you have a strict tree problem or a table problem. This all feels like a meta- version of "social pressure pushed me to use the wrong conceptual model". All the cool kids were doing it...

That said, graphs are dangerous because they are so flexible; you can draw a tree or a table in one and it all seems fine but you're paying all the time in conceptual load and friction.

Microcosm: graph vs table db. In the middle: social pressure dominating data model choices. Macrocosm (relatively speaking): The swing of the pendulum between bodgy vernacular attempts to describe the world (dev don't need some control freak's schema) and esoteric priesthood attempts to describe the world (all knowledge graph structural changes must be initiated by our ontologist...).

Re: GraphQL kinda sucks

#269

Post by 0x20cowboy »

If you have one sever with one end point, and never use other services, graphql doesn’t make sense. Don’t use it.

If you work with a bunch of Micro services, and you’re only a backend developer, you likely don’t understand the problem graphql is solving. The alternatives are almost always way worse.

> No clear path for Api versioning you'll end up with MyQueryV1.01 MyQueryV1.02 MyQueryV1.03

You’re not supposed to version it. That’s what the @deprecation is for.

> It is actually a pain to use, depending on the backend you are using you'll have to manage

Do some front end work, or use your companies API as a client. Something where you have to talk to several services and try to stitch together some sort of combined data with all the latency and unreliability of http over a cell phone network. Then pontificate about how the boundaries between the services are wrong, but never change anything - or better yet change a bunch of boundaries then change the UI to cross different boundaries - then complain about how the UI should always have to exactly match your services because the world should revolve around how you’ve decided to see the problem.

Yikes, where did that come from. That wasn’t directed at you.

Don’t use graphql. When you figure out what it’s for, it’ll be easier to learn.

Re: GraphQL kinda sucks

#270

Post by mst »

platz wrote: post #113
vikR0001 wrote: post #107

Earlier quoted context omitted.

You can do something like this. This query can be created and run on the client: ``` const SAMPLE_JOIN_QUERY = gql` query ($main_data_id: String!) { mainData( main_data_id: $main_data_id) { id main_data_field_1 main_data_field_2 main_data_field_3 related_data{ related_data_field_1 related_data_field_2 related_data_field_3 } } } `; ```

in other words, it's up to the folks writing the resolvers to manifest and implement that join as a nested field.

Which means a lot of the time they end up just caching as hard as they can and hoping that's good enough.

(which is often, honestly, an entirely rational decision in terms of prioritising limited resources, but still makes me sad)

Post reply on HN