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

331–340 of 448 posts

Re: GraphQL kinda sucks

#331

Post by softfalcon »

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…

We avoid this by statically analyzing the queries that are used by the client, generating id’ed persisted queries for them, and only allowing those to be run if you’re un-authenticated/a regular user.

We also have user roles, which, if you’re an admin, you can run raw queries of whatever you want, but basic users are locked to the persisted query options.

It’s pretty cool, definitely adds complexity to our builds/permissions, but it works. We rolled our own, but I think Apollo GraphQL supports this out of the box now.

Not saying people should use GraphQL for everything though. It’s kind of overkill for a lot of apps.

Re: GraphQL kinda sucks

#332

Post by b33j0r »

I loved the idea, then I found out that _doing_ anything devolved into completely custom RPC implementations.

I’m not always RESTful, but in GraphQL the state transfer part is left as an exercise for the reader.

I love natural data models. I also think RPC makes sense when there are clear verbs in a system.

Poor GraphQL. It’s like a Greatish novel where the first half is compelling and intricate, and the last half was rushed by the publisher.

Re: GraphQL kinda sucks

#333

Post by anothernewdude »

You just ignore the main selling point? It solves the latency of getting the data you need. The only alternative is to provide specific extra APIs.

If it's a pain to use, perhaps you're using the wrong language or framework.

You're right that many APIs have maps, those are bad APIs. The map should be happening in your API. The alternative was a poor workaround to stop latency in a REST api.

Re: GraphQL kinda sucks

#334

Post by throwawaymaths »

chpmrc wrote: post #41
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 ch…

Eh I think "rest for external API access, graphql for internal frontend use" is probably a good thing.

Re: GraphQL kinda sucks

#337

Post by valenterry »

spion wrote: post #312
chpmrc wrote: post #290

Earlier quoted context omitted.

> yet since no thought was put into how it might integrate into existing typed languages [...] Says who? > [...] its actually surprisingly difficult to build a type-safe API around it. Again, says who? The consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process. Are you telling me that it's easier to build type safe APIs bas…

> Says who? Says me, and also any other person that has tried to build a type-safe GraphQL query builder > Consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to wat…

It would be helpful if you actually explain how LINQ does it better.

Re: GraphQL kinda sucks

#338

Post by electrondood »

ipaddr wrote: post #296
pragmatic wrote: post #172

Earlier quoted context omitted.

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?

Back in the day we call this role Webmaster. Being able to manage your server, write your code and design the website was what a true developer tried to achieve. It is strange to see developers preferring to stay in their isolated environments and not wanting to touch the entire stack.

This actually made sense back in the day. Now there's significantly more complexity for each part of the stack, tooling, distributed design patterns for scaling, etc. We don't really have "websites" any more, for example. We have apps that run in the browser.

Re: GraphQL kinda sucks

#339

Post by Kaze404 »

deltasevennine wrote: post #198
Kaze404 wrote: post #118

Earlier quoted context omitted.

Maybe I failed to express myself properly, but my point is that saying “X is bad.” (emphasis on the period) is not really saying anything. It’s much more productive if you explain why, how and in what environment X is bad, either before or after, like I did in example #2. In my experience when someone says “X is bad”, the response is often either “haha” (which the subject then changes), or “why” (which leads to perso…

>Maybe I failed to express myself properly, but my point is that saying “X is bad.” (emphasis on the period) is not really saying anything. This logic also works for "X is good." or "GraphQL is good". This doesn't really say anything either and is an equally garbage statement following your logic. But your biases focus on the "bad" because you have a bias towards GraphQL. Either way I don't agree. Saying something li…

There are way too many assumptions in your post. Yes, you're right that I like GraphQL, but:

1) Nowhere in my comments did I say that's limited to negative comments. I think "GraphQL is good" is just as useful (meaning not at all).

2) "Criminals are bad" is not an invalid statement, and neither is "GraphQL is bad" or "GraphQL" is good. But if the purpose is to discuss criminality, and not just add noise to an ongoing discussion, it is also a useless statement. Imagine there's a debate panel going on, someone in the crowd stands up and says "criminals are bad!". Where does that lead the conversation?

3) "The plane is about to crash, please pull up" is an expression of fact, not an opinion, and not even something that warrants or is said in a discussion so I don't think the comparison makes sense. Either way, "GraphQL is bad" is an opinion, not a fact, and thus needs more context to be useful in a discussion.

I'm not going to acknowledge the last paragraph because I'm presuming good faith from you, and I'd rather not turn this discussion into speculation about other comments in this thread or why you're here.

That said, you're definitely right that I'm biased towards GraphQL, but I think we're having different discussions if you think we're discussing GraphQL's merits.

Re: GraphQL kinda sucks

#340

Post by electrondood »

We use GraphQL at my current company, but it's a service that sits between the backend and the frontend and just munges together several different API requests from one. It's... I really hate it. The way we're using it, it simply adds a layer of opacity that makes debugging a client-server issue a giant PITA.

I've worked at a few companies that used GraphQL poorly. I've yet to see it done in a way that makes me think it's the right tool for the job. And I understand the benefit of allowing the client to choose what they want to get back.

Post reply on HN