Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

After 6 years, I'm over GraphQL

bessey.dev

Post reply on HN
Print view View original

381–390 of 721 posts

Re: After 6 years, I'm over GraphQL

#381

Post by WorldMaker »

hansonkd wrote: post #231
theptip wrote: post #228

Earlier quoted context omitted.

The canonical REST solution of query params to add nested fields gets you quite far: GET /myresource?extra=foo,bar sure you over fetch a bit if you have multiple accessors. But agreed, if you have highly nested data especially when accessed with multiple different query purposes then REST might not be the best fit. I think GraphQL has been positioned as a general purpose tool and for that I am with the author, REST i…

I guess depending on the context of a simple app one level could be viewed as far. Any more levels and you have now reinvented GraphQL

OData existed before GraphQL in the wild, it's possible to suggest GraphQL reinvented OData.

https://www.odata.org/

Re: After 6 years, I'm over GraphQL

#382

Post by Hamuko »

drpossum wrote: post #371
chuckadams wrote: post #260

I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mi…

> used it in a small project, and liked almost every bit of it This is the difference

I don't know, I used GraphQL in a small project and I absolutely hated it. I mean, it was definitely workable, but I just absolutely hated writing those queries. Why am I having to write these again? It's not my website, so why am I in charge of writing the API?

Re: After 6 years, I'm over GraphQL

#383

Post by bilater »

I never understand how people end up needing overly complex queries (REST or GRAPHQL). Maybe it's harder to coordinate in bigger orgs but I have almost always found its better to go to the DB, create some logic there like a new table or sql view and do a simple query from the client. It keeps thing way more performant and simple.

Re: After 6 years, I'm over GraphQL

#384

Post by smaudet »

hansonkd wrote: post #285
smaudet wrote: post #271

Earlier quoted context omitted.

> With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes. This is akin to saying that "directly exposing the database is easier, you only have to change things if the data changes". And yes this is true, but when the data changes, or the environment changes, the paradigm falls apart a bit, no? Which is what the backe…

> This is akin to saying that "directly exposing the database is easier Far from it actually. I am saying that in practice the data and queries that you perform on your Database actually tend to stabilize and you add less and less as time goes on. By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use, you have to do less and less backend work when compa…

> By Allowing the frontend to select what combination of these pre-approved queries that you already approved it can use

Sure, so you are just filtering raw database access then. That doesn't make it any different - and, you still need to approve and filter these queries, so what exactly have you saved? I.e. either the front end engineers can change these filters, or not, so it amounts to the same thing in the case they can.

> I mean saying GQL doesn't scale for big apps is over looking one of the largest Corporate Software Orgs (FB) created and use it in production purposefully for managing large software APIs.

That's not a great argument, though, saying a large company with many resources is capable of supporting something does not make it a sustainable technical decision. They likely also have a very specific work structure they use to make it for them.

In fact thats a strong reason not to use it, if it requires enterprise level resources to use it effectively. There is a big difference between technologies that scale to enterprise and technologies that require enterprise...

It still comes down to, if you can achieve 99% of the same thing with autogenerated REST apis and a couple page specific apis, what, exactly, is worth the considerable increase in complexity for that remaining 1%? Making things regularly more complex is a hallmark of failed, bad technologies, and I suspect GraphQL will see the dustbin like SOAP did...

Re: After 6 years, I'm over GraphQL

#385

Post by hansonkd »

BiteCode_dev wrote: post #378
hansonkd wrote: post #333

Earlier quoted context omitted.

> more complex, more expensive to maintain, consuming more resources, Idk. Strawberry GQL and most GQL libraries are maybe equally as complex as the REST libraries for the same language. Strawberry and FastAPI I would say are equal in complexity and configuration. It would be hard for me to say GQL is more expensive or consumes more resources. Opposite of the purpose and most uses of GQL.

In stawberry you make a method per field you want to retrieve, I would say it is indeed more complex and costly.

What? Its a method per collection you want to return. or else it is a type annotation. Exactly as complex as FastAPI or any other typed system.

Re: After 6 years, I'm over GraphQL

#386

Post by trallnag »

noduerme wrote: post #9

Haven't used GraphQL but the idea of exposing queries from the client directly to the DB is totally bananas, even behind a login with a separate auth. Even just explaining your DB structure is a thing you should not do.

Usually you put in views between your "private" DB structure and GraphQL

Re: After 6 years, I'm over GraphQL

#387

Post by [deleted] »

mst wrote: post #347
dventimihasura wrote: post #290

Earlier quoted context omitted.

PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation, though naturally it does follow rules. For example, Hasura does the same thing, and among the rules that it follows is that it uses `LEFT LATERAL JOIN` between tables (at least, on PostgreSQL). Full disclosure, I work for Hasura, so I'm not super familiar with the style of SQL PostGraphile generates but…

> PostGraphile compiles GraphQL directly to SQL. The SQL is "custom" in that it's specific to the GraphQL operation Yes, that's why I said GraphQL and -corresponding- SQL, I was hoping to find something that showed me the SQL for each of half a dozen or a dozen examples ... though the debug option there will let me point the out-of-the-box CLI at a pre-existing database and have a look at as many examples as I like,…

[deleted]

Re: After 6 years, I'm over GraphQL

#388

Post by chuckadams »

drpossum wrote: post #371
chuckadams wrote: post #260

I must be the only one who found GraphQL, used it in a small project, and liked almost every bit of it. I used Apollo Client and graphql-codegen to generate types and functions for Vue 3, and nothing else could touch it. It wasn't all smooth sailing of course: I did find defining new scalar types to be fiddly, and I couldn't really even make proper use of union types, directives, or even enums due to the impedance mi…

> used it in a small project, and liked almost every bit of it This is the difference

Perhaps, but isn't everybody saying it's strictly for the Billion-User Big Dogs? I admit I'm a small-timer nowadays, but having been a cog in a couple mega-corporate machines, I would have walked over my grandmother to get the strongly-typed tooling I get with graphql.

Re: After 6 years, I'm over GraphQL

#389

Post by WorldMaker »

svachalek wrote: post #296
cess11 wrote: post #276

Earlier quoted context omitted.

JSON winning over XML is like saying CSV won over MySQL. They aren't equivalent. Much like CSV, JSON isn't particularly standardised and different parsers and writers will do different things in some situations. Usually it doesn't matter, but when it does you're probably in for a lot of pain. If you handle structured data and the structures might change over time, JSON isn't a good fit. Maybe you'll opt for JSON Sche…

What's missing in ECMA-404? Never had a problem with JSON parsers or writers, using it all day every day for decades. It's crappy in some ways, sure, like lack of full floating point support, but standardization is not an issue. XML is mostly already lost on the current generation of developers though, much less future developers. Protobuf and cousins generally do typed interchange more efficiently with less complexi…

There are a lot of proponents that some or all of the "JSON5" [1] improvements should be standardized by ECMA as well. Especially because there is a mish-mash of support for such things in some but not all parsers. (Writers are a different matter.) Primarily comments and trailing commas, are huge wish list items and the biggest reasons for all of the other "many" variant parsers (JSONC, etc).

[1] https://json5.org/

Re: After 6 years, I'm over GraphQL

#390

Post by troupo »

abound wrote: post #119

Having worked extensively with OpenAPI, GraphQL, plain JSON/HTTP, and gRPC/Buf Connect services, most of this rings true for me. One thing the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature. This mitigates a lot of the gnarly performance and security issues because the attack surface goes from "arbitrary queries" to "queries you've already '…

> the author doesn't mention is that you can limit the set of queries clients can call in a GraphQL service, by hash or signature.

Then it's just REST with extra steps and none of the benefits

Post reply on HN