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

431–440 of 448 posts

Re: GraphQL kinda sucks

#431

Post by aleclm »

loosescrews wrote: post #262
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).

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

HTTP/2 helps with the network layer, but your backend will still handle requests one-by-one. Depending on what you need to do, this might make a hell of a difference.

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

There's this:

    https://www.graphql-code-generator.com/
But yeah, on a second look I expected to find more. Anyway, having a standard way to do things instead of relying on one specific piece coupled to some language (swagger), it's certainly better. On the other hand REST APIs have a much longer history, so I guess it's normal for them to have more tools.

Re: GraphQL kinda sucks

#432

Post by spion »

valenterry wrote: post #418
spion wrote: post #417

Earlier quoted context omitted.

> I've never written a GraphQL scema or query by hand, always used a good wrapper Could you give me an example of a good client wrapper that doesn't require you to write queries as strings?

Not sure if you consider it "good" but I've used this one quite successfully: https://ghostdogpr.github.io/caliban/docs/client.html#query-...

Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem.

To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder (https://typed-graphql-builder.spion.dev/) and I can think of several ways the language could've been designed to make it easier to write typed query builders.

This is not without consequences - since its quite hard to write the builder, most tools available for code generation (https://www.graphql-code-generator.com/) are built around editing GraphQL strings and will try to find them in your code and add type assertions. Additionally the rest of the ecosystem tools are built around supporting this workflow (graphql playgrund, etc)

Re: GraphQL kinda sucks

#433

Post by OrangeMusic »

blacklight wrote: post #372

We're forgetting an elephant in the room. REST APIs make it easy to cache data. Do a GET /api/objects/123, and if the object hasn't changed since last time we'll hit the cache. You can't do that with GraphQL, because a URL doesn't descrive a single resource. What I like doing is to create a REST layer that sits just on top of the database, and a GraphQL layer on top of it that allows all kind of fancy queries. Yes, H…

You may find this article interesting: https://xuorig.medium.com/no-graphql-persisted-queries-are-n...

Re: GraphQL kinda sucks

#434

Post by OrangeMusic »

OJFord wrote: post #344

You forgot number 1: '200 your graphql request succeeded, here are all your errors'. ...I get it, the gql request did succeed, I've previously described it as like a 'layer 8' on top of HTTP: the problem being that all the tooling is for HTTP. I wish 'REST' was one thing - with generated OpenAPI servers/clients & 'links' for example we could achieve what gql sets out to, if only there was a single way to do it.

> 200 your graphql request succeeded, here are all your errors

I'm not sure how that's a problem? The client knows where to look for errors: not in the http response code but in the JSON payload. Why is that an issue?

Re: GraphQL kinda sucks

#435

Post by mrbonner »

I’m evaluating Graphql for my service at this time. This service could be public facing in the future. A majority of the complaints about it that I learn in this post is about accidentally making your GraphQL’s nested graph structure an exploit.

What do you think if I just use graphql for the typed schema, flex return objects without the “graph” part? Or at least I would have a very shallow graph without nested data structure. Do you think it would help in this case?

Re: GraphQL kinda sucks

#436

Post by CRConrad »

diarrhea wrote: post #147
NonNefarious wrote: post #88

Earlier quoted context omitted.

Yep. I worked at a place that fired almost its entire programming staff because they insisted on using Visual C++ to build a CRUD app, while a team of contractors built a prototype in Visual Basic. Needless to say, the VB app worked fine and became the product.

If you don't mind, would you explain this more? I don't understand the implications; VB does sound "worse" than Visual C++ for such a job, from an outsider perspective?

> VB does sound "worse" than Visual C++ for such a job

Huh? No no, on the contrary: Straightforward CRUD apps, that's exactly what VB was built for and excels at. Only Delphi is better.

The thing about "Visual" C++ is that it isn't (or at least wasn't, last I looked) really very visual at all. And that sucks for building simple in-house CRUD apps, where the VB / Delphi drag-and-drop UI builder paradigm is a huge productivity multiplier.

Re: GraphQL kinda sucks

#437

Post by x86x87 »

adra wrote: post #229
x86x87 wrote: post #154

Earlier quoted context omitted.

This nails it. Had the "proviledge" of needing to secure a GQL endpoint and it's a mess. AuthZ? What's that? + Runaway queries that kill the database? check! + Caching? Lol. Setting aside security and scalabilty for a second: Ifeel like GQL is at its best a complicated database driver, with the data types being defined and implemented twice: once in the DB layes, once in the backed.

If you're testing gql as anything remotely similar to a database facade, you've already lost. GQL is meant to provide functionality that generally happens to be data backed. If you want to push all your work to the frontend and treat gql as a db shim, you're solving the wrong problem in the wrong ways.

That's a lot of words, but what does it mean? What does "generally happens to be data backed" means? Are you suggesting that GQL add value in the transforms that it's creating? In how is glueing together multiple types of data?

Re: GraphQL kinda sucks

#438

Post by CRConrad »

hn_throwaway_99 wrote: post #119
cudgy wrote: post #70

Earlier quoted context omitted.

You are right that this arrogant attitude is juvenile, but it is prevalent amongst humans in all areas. Unfortunately, there would be few developers to work with if you apply the policy of not working with arrogant, dogmatic developers.

Strongly disagree, primarily because when this type of attitude infects dev teams it is usually a cultural issue, not an individual one. The primary, inviolable value I have, and look for, in dev teams is "strong opinions, loosely held". Meaning I want to work with engineers that have the experience, motivation and intelligence to have strong opinions about how things should be done, but it's also critically importan…

> look for, in dev teams is "strong opinions, loosely held".

Rather strong opinions, not super-strongly held.

If you know you're somewhat flexible in your opinion, it's going to be quite strong, but not all that strong. OTOH, if you have an even somewhat strong opinion, it's no use letting yourself be swayed from it all that easily; make them advance quite a good argument for it first.

But then, depending on how heavily you load your adjectives, maybe that's what your (admittedly much more pithily put) version meant, too. I just wanted to put the modifiers out there lest someone read the maxim at its strongest.

Re: GraphQL kinda sucks

#439

Post by CRConrad »

mechanical_bear wrote: post #193
eknkc wrote: post #132

Earlier quoted context omitted.

So you are sure that some tech that you avoided completely (and I assume have zero experience in) is a terrible piece of software. Great. What is your take on the postal service structure of Turkmenistan btw?

Their service scope is waaaay too broad, no reason to be responsible for quasi banking services, traffic fine payment, and utility payment processing.

Services like those are part of the scope of quite a lot of national post institutions, and actually for quite valid reasons.

Re: GraphQL kinda sucks

#440

Post by chpmrc »

spion wrote: post #432
valenterry wrote: post #418

Earlier quoted context omitted.

Not sure if you consider it "good" but I've used this one quite successfully: https://ghostdogpr.github.io/caliban/docs/client.html#query-...

Its a reasonable looking wrapper. Could benefit from the ability to build queries with variables, although not sure if that would be useful in the Scala ecosystem. To make it clear, I disagree I'm conflating things. I'm currently working on a TypeScript based graphql builder ( https://typed-graphql-builder.spion.dev/ ) and I can think of several ways the language could've been designed to make it easier to write type…

> I can think of several ways the language could've been designed to make it easier to write typed query builders.

Would you like to share them? Have you tried submitting your suggestions to the GraphQL core team?

Post reply on HN