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

361–370 of 448 posts

Re: GraphQL kinda sucks

#361

Post by acdha »

squidsoup wrote: post #301
demarq wrote: post #257

Earlier quoted context omitted.

That's the theory. In my experience at both large and small organisations is that NONE of the theory makes it into practice. Some reasons: - Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A. - Backenders never optimise column selection. You may think you are really optimising by sending a GQL query for one column, but t…

> Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A An unfortunate problem that really only exists with Apollo. Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies.

> Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies

In the scenario described, wouldn't this lead to the same problem because someone copied the code or reused a utility from another project and so they have at least the superset of those dependencies plus whatever new ones they added?

Re: GraphQL kinda sucks

#362

Post by tveita »

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.

You can have N frontends for one backend. If you need a new iOS app you will probably hire a team of iOS developers, not have all of your product teams learn Swift.

If your API looks like this...

  /ios-app/v1/landing-page
  /android-app/v1/landing-page
  /android-app/v2/landing-page
  /windows-mobile/v1/landing-page (legacy)
  /web/v5/...
where each platform has its own subtly different UI structure, the ability for frontend teams to get basically an arbitrary JSON structure of their choosing starts looking worth the extra work on the backend.

You might not encounter this problem at any point that's fine - there are other ways to avoid it, like having a cross-platform codebase. I have "hand-rolled" similar solutions to the GraphQL field selection before, and I would use the GraphQL protocol if I were to do it again today.

Re: GraphQL kinda sucks

#363

Post by Aeolun »

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

Think very hard about your API. And absolutely do not ever introduce any query called V1 or V2.

Re: GraphQL kinda sucks

#364

Post by Aeolun »

agucova wrote: post #323
pan69 wrote: post #298

Earlier quoted context omitted.

> Note that even if you use graphql for a private api to your web client, folks will reverse engineer it and use it for their own purposes. There are no private apis on the web. How is this a GraphQL specific problem?

At least compared to classical REST, usually access is limited to whatever the programmer explicitly chose to add, instead of being open by default.

That’s weird. You explicitly choose what to add to your GraphQL API too. If you’re just setting up a random library that exposes your entire database, that’s no fault of GraphQL.

Re: GraphQL kinda sucks

#365

Post by Aeolun »

ryanbrunner wrote: post #346
masklinn wrote: post #226

Earlier quoted context omitted.

I think an other thing with graphql is it reduces friction when trying to discover what your API should be. So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected). Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API end…

In my experience, "let's do something non-scalable and obviously wrong while we're exploring the problem space and replace it with something better before shipping" reduces to "let's do something non-scalable and ship to production" 100% of the time.

So you are saying it works? At least all the production systems where we’ve done this work fine, they’re just inefficient, feel vaguely dirty, and are unpleasant to work on. They’re still bringing in boatloads of money though.

Re: GraphQL kinda sucks

#366

Post by ec109685 »

tshaddox wrote: post #285
thr0wawayf00 wrote: post #253

Earlier quoted context omitted.

It's also not that hard to implement attribute filtering with REST endpoints. People make a big deal about being able to control the shape of your API responses with GraphQL, but this completely achievable with standard REST APIs as well.

Sure, you could have a syntax for requesting (potentially recursive) nested resources in the query string of a REST API, and there are some systems that do something close [0], but if you do it’s probably a less friendly syntax than GraphQL and has all the same problems as GraphQL regarding performance and rate limiting. [0] A very simple convention for including nested resources in a JSON API: https://www.jsonapi.ne…

Agree with this. We created our own nested query language using matrix params and path separators to let the client query for nested sub-resources, including filters against collections.

It’s pretty neat but nice graphql standardized it so things like consoles and other tools can be written against it.

Re: GraphQL kinda sucks

#367

Post by Aeolun »

pragmatic wrote: post #172
breckenedge wrote: post #23

Earlier quoted context omitted.

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.

I think you are saying why not combine specialists on one team vs the “everyone is fullstack+devops” amateur hour dystopia that is becoming all too common?

> the “everyone is fullstack+devops” amateur hour dystopia that is becoming all too common?

What a weird thing to say. That was the original state. At some point people started splitting things up because they felt that would be better (or they just weren’t capable of grasping more than one thing?), but I’m extremely sceptical of all this specialization.

Re: GraphQL kinda sucks

#368

Post by bigmattystyles »

I've asked before and I've never got a straight answer, but why isn't ODATA more popular? It's open, though I know SAP and MS have botched their ecosystem mostly via inaction. But to me, it's great, SQL -> ORM -> ODATA, for 95% of what I need, it fits perfectly.

Re: GraphQL kinda sucks

#369

Post by Aeolun »

TedDoesntTalk wrote: post #52
breckenedge wrote: post #23

Earlier quoted context omitted.

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.

> good reasons to divide product teams between frontend and backend? People specialize in different things. A great React developer may not be a great Java developer, and vice-versa

An intermediate Java and React developer is more than the sum of the parts. Especially when considering a whole team.

You may need one or two really great React and/or Java developers.

Re: GraphQL kinda sucks

#370

Post by wallfacer120 »

stickfigure wrote: post #232

The biggest problem with graphql is that you have to do a lot of non-obvious work to harden your system against DOS attacks or people that want to fly by and download your whole database. It's easy to construct a query which puts unreasonable load on your system. The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system. If you want to see the kind of work you actuall…

How could someone reverse engineer anything other than your data model from gql queries?
Post reply on HN