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

301–310 of 448 posts

Re: GraphQL kinda sucks

#301

Post by squidsoup »

demarq wrote: post #257
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…

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.

Re: GraphQL kinda sucks

#302

Post by chpmrc »

> It is actually a pain to use, depending on the backend you are using you'll have to manage two or more type systems if there are no code first generates in your language

This is a shortcoming of the language, not of GraphQL.

> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be

If you ever tried to cram a JSON like payload in a GraphQL field you'll know why this limitation is in place. It quickly starts getting abused by clients and you end up adding validation, which you might as well have codified in a properly structured type. For blobs you can just send encoded strings (JSON, base64, binary, you choose).

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

The whole point of using something like GraphQL is that you don't need or even want versioning. You can still deprecate fields (and remove them according to your deprecation policy) but in general you can just keep adding fields/types without removing the old ones until you are sure consumers don't need them any more. So there's no breaking change and consumers can transition to the new fields whenever they want. Something else you start appreciating when you have multiple, heterogeneous consumers of your API.

Or you can just add the version to your schema URL, e.g. `/graphql/v1/` and then route your queries based on that, which kind of defeats the purpose.

> Invest your time in a simpler solution then running to GraphQL first

GraphQL is as simple to set up as anything else, assuming the language has good support for it. If it doesn't that's, again, a limitation of the language, not of GraphQL.

GraphQL solves a ton of problems related to typical JSON APIs' conventions, since JSON isn't inherently "schemable" unless you generate something like an OpenAPI spec which is, arguably, more complicated. There might be superior alternatives (I've never tried JSON schema) but I think all the pain points you described can be easily solved one way or another.

Re: GraphQL kinda sucks

#303

Post by csnweb »

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.

Re: GraphQL kinda sucks

#304

Post by YZF »

ako wrote: post #297
YZF wrote: post #192

Earlier quoted context omitted.

Nobody seems to get the idea of building software out of pieces with well defined APIs any more . I would say it's not possible to build large software without adhering to this principle but I seem to be proven wrong. You can build large poor quality software and just throw more people at it. The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the te…

What is a well defined API to access a lot of related datasets if you have 100s of external users, using it for 10s of different types of use cases? Compare it to a database, what if you couldn't use random queries with SQL, but only had the option to call stored procedures?

It's the narrowest abstraction fitting those use cases. A database by its nature is a generic component. So sure, the piece of your software that's "SQL database" has a SQL interface, pretty quickly you'd want some abstractions on top of that around the different uses of that database.

The problem is when genericity diffuses its way into a large system it becomes impossible to maintain. How do you refactor a code base when everything everywhere is just SQL queries. If you want to change the schema how do you know you're not breaking anything? The short answer is you don't and so the software becomes incredibly brittle. The common workaround is testing but you can never test everything and now your tests also become coupled to everything else making things even more difficult to change.

The database in your example, while being generic is already an abstraction of sorts. Now if you're building lessay gmail the external users should see "create email", "get all emails", vs. issuing SQL queries to the database. That makes it easier to change the two pieces (client and server in this simplified example).

Re: GraphQL kinda sucks

#305

Post by randytandy »

rootext wrote: post #149

> It doesn't support map/tables/dictionaries. This is actually huge. It's actually easy to implement. Just define custom scalar type: scalar JSON type MyObject { myField: JSON } https://www.apollographql.com/docs/apollo-server/schema/cust...

Hey thanks for taking the time to find the resource

I have used this before this works to get past the errors but doesn't actually solve the issue GraphQL tries to solve. This just hides it so you have to deal with it months later.

- The consumers don't know what the JSON looks like unless they test the query or get told what the query is explicitly. This means that the schema definitions don't capture the problem that the graphql try's to solve "describe your data that you want"

- also some of the other languages that aren't Javascript don't have GraphqlJsonScalar

I think that supporting dictionaries/maps/tables as apart of the Graphql language spec could of been possible as the key and value types are static. They are also iterable so it should be fairly straight forward for a consumer to deal with the data returned.

Re: GraphQL kinda sucks

#306

Post by nogridbag »

kortex wrote: post #289
loosescrews wrote: post #262

Earlier quoted context omitted.

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

I believe by batching they mean operating on collections of entities instead of single ones. So you may have POST /pets to create a single pet from a json object, but what if you want to add a hundred pets at once? Even with multiplexing, this is often way less efficient. Often the solution is to have POST /pets/bulk which takes a list of objects.

I suppose it depends on the domain, but in all the APIs I've created bulk operations are fairly rare. I guess if you know upfront that your API would involve heavy bulk operations then seeking a tool that makes that more performant would be beneficial.

Re: GraphQL kinda sucks

#307

Post by YZF »

withinboredom wrote: post #282
pphysch wrote: post #221

Earlier quoted context omitted.

This is one of the strengths of gRPC, it forces and centralizes the (mostly type safe) API design from the get-go. Also tends to use a lot less bandwidth.

The biggest issue with GRPC is that it is only suitable for stateful languages (iow, languages that can hold values and share them between requests). GRPC is basically worthless for stateless languages and unusable. These stateless languages also don’t work well for websockets either, so it is what it is. Until they solve the stateful part, I’m not using it or recommending it to be used anywhere. Bandwidth is cheap,…

What's a "stateful language"? Can you give an example here? gRPC is orthogonal to whether an API relies on state or not.

Re: GraphQL kinda sucks

#308

Post by chpmrc »

jwr wrote: post #191
chpmrc wrote: post #36

Earlier quoted context omitted.

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…

> That's like saying SQL is crap because you need to build queries by hand If we want to use these terms, then SQL is indeed crap, because you need put query parameters in-band instead of out-of-band. This led to numerous exploits over the years, as it's difficult to ensure the data is correctly escaped. GraphQL just repeated the same mistakes.

Calling SQL crap just because there's a way to abuse it is like saying C is crap because I could do `int * userGuess = get_number_from_user(); * userGuess;` with nothing more than a compiler warning (if I'm lucky).

Would be nice if we all stopped with these blanket statements and just focused on evaluating individual pros/cons of things.

EDIT: formatting of pointer

Re: GraphQL kinda sucks

#309

Post by chpmrc »

oznog wrote: post #246
chpmrc wrote: post #36

Earlier quoted context omitted.

> I was appalled that in this day and age, this hyped silver bullet basically requires me to build queries using strings. That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment). There…

> The quality of posts and comments here used to be a lot higher but it's slowly turning into a [..] You can go on with your GraphQL, Kubernetes, gigantic frameworks, and pages with 3MB of JS if you want. And let's see what stands the test of time.

Well, GraphQL aside I've been using the same stack for almost ten years and it's only becoming more and more popular so I'd say I'm doing pretty well in terms of choosing the tech, thanks for your concern though!

Re: GraphQL kinda sucks

#310

Post by pphysch »

withinboredom wrote: post #282
pphysch wrote: post #221

Earlier quoted context omitted.

This is one of the strengths of gRPC, it forces and centralizes the (mostly type safe) API design from the get-go. Also tends to use a lot less bandwidth.

The biggest issue with GRPC is that it is only suitable for stateful languages (iow, languages that can hold values and share them between requests). GRPC is basically worthless for stateless languages and unusable. These stateless languages also don’t work well for websockets either, so it is what it is. Until they solve the stateful part, I’m not using it or recommending it to be used anywhere. Bandwidth is cheap,…

Is this bait? Lol
Post reply on HN