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

341–350 of 448 posts

Re: GraphQL kinda sucks

#341

Post by spion »

valenterry wrote: post #337
spion wrote: post #312

Earlier quoted context omitted.

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

LINQ lets you write SQL queries using the (.NET) language in which you write all your other code. This means you get to take full advantage of the language (and language service) features, including the typechecker, code completion etc.

Examples: https://www.c-sharpcorner.com/article/writing-complex-querie...

The hard bit here is making sure the language type-checker is fully aware of the involved types, both while writing the query as well as while selecting the results to be returned

This approach has since been copied in more capable languages. One of my favorite examples lately is Rust's Diesel: https://diesel.rs/ (see the "complex queries") example.

A query language designer aware of the above lessons learned with SQL might take special care to ensure their new query language is easier to model in existing languages. For example, they might consider an alternative OOP or FP based syntax, or to generalize they might put some thought into what would make it easy to write a type-safe query builder. After all, while SQL was developed in 197x and we had a different model for data access early on (stored procedures instead of flexible language-integrated queries) so its easier to understand that we didn't consider integration with other languags. TypeScript already did exist when GraphQL first appeared in 2015, and it's been 7 years of LINQ at that point.

Yet, we still went the stored procedures route. Tools such as graphql-codegen [1] require you to regenerate your types every time you edit your query strings

[1]: https://www.graphql-code-generator.com/

Re: GraphQL kinda sucks

#342

Post by ryanbrunner »

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…

99% of the time you don't need to be recursive though. Field filtering with 1 level of expansion for related resources solves 95% of problems for you, and if you're implementing something on your own API, you can have a custom route for the 5%.

GraphQL falls into the same trap that a lot of things do IMO - it assumes that because 5% of things are complex, that you need a solution that can deal with that complexity for 100% of your API, which needlessly complicates everything else.

Re: GraphQL kinda sucks

#343

Post by andrewingram »

csnweb wrote: post #303
jeroenhd wrote: post #299

My problem with GraphQL: it doesn't support generics. I'm fine with request batching/complexity overloads/all that craziness. Most GraphQL libraries have some kind of protection mechanism in there, or allow you to artificially split up the request and forward it to your application load balancer. I'm also fine with a lack of API versioning, especially for internal services. Hell, I'll even tolerate the lack of dictio…

I think you may be should give a code first GraphQL a try, you can pretty much everything you want that way. You can write high level functions for pagination or whatever that way and have a base object that you can extend for all Types implementing the interface. I really don’t know why schema first seems to be the default, it’s really unflexible.

Strawberry (a GraphQL lib for Python) actually supports using generics to define types, it’s often used for supporting repetitive structures like pagination.

Re: GraphQL kinda sucks

#344

Post by OJFord »

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.

Re: GraphQL kinda sucks

#345

Post by initplus »

mattbillenstein wrote: post #208
toolz wrote: post #187

Earlier quoted context omitted.

because either the boilerplate is massive or the libraries do so much for you that you have to specialize in understanding the libraries magic - front-end plus back-end code for graphql is almost always more than a traditional REST api and I mean a lot more code, not just a bit more, so more code is strongly correlated with more problems. The exception is when you use heavy libraries that have magical APIs. Then you…

What tooling are you using that requires a massive amount of extra code? You need to define the schema and write resolvers, but that's sorta similar to what you might do in REST on the backend. On the frontend, you have a choice to use some of the heavier libraries that support all of the features (like subscriptions) - but otherwise, you can just POST a gql query to the server and it will return a blob of json, whic…

Why use graphql at all if you are going to use it just like a traditional REST api? You don't get much of a benefit from the client selecting which fields it wants, the backend probably fetches the entire DB row anyway so why not just send the whole thing over?

The limitations of the query language make code size explode the moment you step outside simple toy examples. It doesn't have any concept of a JOIN, or of the actual relationships between your types (graphql has no concept that me == me.parent.child). You end up writing data loaders for every type so that loops in your schema can be resolved efficiently.

Managing permissions is so much more of a pain compared to REST because exactly what data is returned is so much more dynamic. If you have some confidential data nested 10 layers deep in the query, you get two choices. Either fail the entire query with a NotAllowed based on one deeply nested field that the client maybe does not even care about, or you have to make your schema super loose and make every single field that's subject to permission management nullable. So much easier on a REST endpoint because the response is more constrained.

Re: GraphQL kinda sucks

#346

Post by ryanbrunner »

masklinn wrote: post #226
mLuby wrote: post #76

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…

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.

Re: GraphQL kinda sucks

#347

Post by initplus »

vikR0001 wrote: post #107
NonNefarious wrote: post #84

Earlier quoted context omitted.

I thought it was supposed to do this, but then discovered that it has no way to express joins. Has this been addressed? I don't see how you can decouple the back-end data from front-end queries without that.

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 } } } `; ```

Right, but on the backend someone had to think ahead of time that somebody would want to JOIN between those two types, and remember to put the field in place, and implement the JOIN.

Re: GraphQL kinda sucks

#348

Post by initplus »

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.

Our monitoring says all the requests are 200 OK, why is the client down?

Re: GraphQL kinda sucks

#349

Post by mabbo »

mattbillenstein wrote: post #202
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,…

Why do you hate it? What tooling are you using? I found it fairly painless in Python - Graphene/Flask.

I joke mostly. Coming from a REST based background it was really foreign and convoluted to me.

Until I understood the point, the organizational decoupling. Then it clicked why it's great.

Re: GraphQL kinda sucks

#350

Post by nsenifty »

spankalee wrote: post #239

Among the many problems with GraphQL are 1) That it doesn't deal in graphs, but trees, and 2) It's not a query language, but an RPC language with result subsetting I would love to see something similar to GraphQL that could return actual graphs. Like in the canonical Books/Authors example, a query over books that included the authors would return Books with _references_ into an Authors collection so that authors were…

#1 is not a real problem on practice. If the concern is payload size, gzip solves it for the most part. If the concern is consistency (e.g. there's an update to author and it needs to propagate to all books from this author), most graphql clients + view frameworks already handle it by maintaining an id based cache and notifying all users of the said object when something changes.
Post reply on HN