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

581–590 of 721 posts

Re: After 6 years, I'm over GraphQL

#581

Post by chuckadams »

int_19h wrote: post #467
svachalek wrote: post #296

Earlier quoted context omitted.

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…

It's focused almost entirely on syntax and ignores semantics. For example, for numbers, all it says is that they are base-10 decimal floating point, but says nothing about permissible ranges or precision. It does not tell you that, for example, passing 64-bit numbers in that manner is generally a bad idea because most parsers will treat them as IEEE doubles, so large values will lose precision. Ditto for any situatio…

GraphQL does define the size of its numeric types: Ints are 32 bits, Floats are 64, so if you have a bigint type in your db, you'd best be passing it around as a string. Any decent GQL implementation does at least check for 32-bit Int overflow. Several people have independently come up with Int53 types for GQL to use the full integer-safe range in JS, but the dance to make custom scalars usable on any given stack can be tricky.

Re: After 6 years, I'm over GraphQL

#582

Post by fouc »

hackthemack wrote: post #564
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…

I'm always reminded of the mantra "Choose Boring Technology" https://boringtechnology.club

Re: After 6 years, I'm over GraphQL

#583

Post by dventimi »

hackthemack wrote: post #564
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new. "Maybe implementing CORBA for message passing is over complicating it." "Maybe us…

"Maybe using a general-purpose programming language instead of just SQL is overcomplicating it," said I every day of my life for the past 25 years. Oh well. You can't fight City Hall.

Re: After 6 years, I'm over GraphQL

#584

Post by shagie »

I've come to believe that the "right" way to do things now is alternating smart / dumb layers.

If you have two smart layers adjacent to each other (and GraphQL is a smart layer) then the interconnection between the two and the conflicting abstractions of data becomes an issue.

By having something dumb (REST endpoints) between the business layer and the complexity of the front end, it is possible to have reasonable abstractions writing to the REST endpoints and an abstraction of the payloads that the endpoints provide into what is needed in the front end application.

It seems that GraphQL works best when the backend has minimal business logic and the thing that is calling GraphQL likewise has minimal logic -- and all the logic is contained in the GraphQL query itself.

But if you're finding complexity in getting things into GraphQL and manage permissions and mutations... or you've got the complexity of the front end where the data model the front end needs to work with doesn't align with the GraphQL model ... then you've got complex solutions abutting each other and those spots is where the pain will be found.

Re: After 6 years, I'm over GraphQL

#585

Post by [deleted] »

vbezhenar wrote: post #542
afiori wrote: post #61

Earlier quoted context omitted.

> In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple. You should log deprecation warnings. But also if the client is composing urls/params manually then you are not doing REST, you are doing RPC. Rest APIs should mainly use HATEOAS hyperlinks to obtain a resource.…

REST is just a short name for RPC over JSON. Nobody does real Fielding's REST.

[deleted]

Re: After 6 years, I'm over GraphQL

#586

Post by joegibbs »

wasyl wrote: post #540
joegibbs wrote: post #514

Earlier quoted context omitted.

Yeah but then you’ve basically just remade REST, but the queries are stored in the frontend instead.

I don't understand this argument, how is it "remade REST" if you still don't need to implement and maintain an endpoint with exactly the data that clients need? Persisted/whitelisted queries require much less backend effort, and are decidedly different from REST, the only similarity is in having a closed set of possible actions. Perhaps you're thinking in terms of public APIs where I agree limiting available GraphQL…

I might be thinking about this the wrong way, but with GraphQL you're writing a query (in the GraphQL syntax) on the frontend which gets whatever data the frontend needs for whatever it's doing, and that query is interpreted by the backend to fetch specific data. But if you're whitelisting specific queries, which has to be done on the backend, what if you just move the queries themselves to the backend, and call them from the frontend by specific names for shorthand? And then from there, what if you refactored it so that each "query" was just a function with an associated endpoint?

Re: After 6 years, I'm over GraphQL

#587

Post by chuckadams »

feoren wrote: post #517
culi wrote: post #456

Earlier quoted context omitted.

GraphQL is meant to be used along side a very smart client-side cacheing library like Apollo The best practice for GQL is to make frequent, small, queries (Apollo handles batching them) throughout your application. Apollo won't do any extra work to fetch new fields if they're already in the cache Not to be that person because I understand there's always edge cases, but in general with GQL if your queries are highly c…

"Make frequent small queries and let a smart cache do the right thing every time" sounds like "make a perpetual motion machine". It just sounds like a fundamentally difficult problem with unavoidable tradeoffs. I admit I don't know the details of Apollo, but I find it hard to believe that a caching layer magically solves everything without introducing very gnarly bugs. A cache layer makes concurrent editing harder, f…

The Apollo cache doesn't magically solve everything, certainly not concurrency. It's a state store like redux/pinia/mobx, with automatic normalization plus other goodies like being able to query/mutate the store locally with gql if you want. Doing N+1 cache-only queries is also no big deal, though I don't do so myself. They probably should have called it a state store and not a cache, but whatevs...

Re: After 6 years, I'm over GraphQL

#588

Post by hamandcheese »

pyr0hu wrote: post #487
joshstrange wrote: post #374

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

Can you give an example for the permission issues that you had with GQL and would've been easier in REST? Genuinely curious, as I'm implementing a GQL backend with simple permission handling and haven't run into anything yet, but I wanna know what could await me

Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something.

A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection.

Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient!

Now every user can inspect all orders of every other user, if that user has left a review.

Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.

Re: After 6 years, I'm over GraphQL

#589

Post by acdha »

int_19h wrote: post #457
jayd16 wrote: post #433

Earlier quoted context omitted.

Its not JSON over XML. They're saying JSON REST won over _XML and SOAP_.

Those two are kinda orthogonal, and while there was some overlap for adoption, it was fairly common to serve XML over REST early on (because more languages and frameworks had proven-quality XML parsers out of the box, so it was easier for the clients to handle). JSON won in the end mostly because it was easier to handle in JS specifically, which is what mattered for the frontend. Then other languages caught up with t…

> JSON won in the end mostly because it was easier to handle in JS specifically, which is what mattered for the frontend

Browsers had XML parsers before they could handle JSON directly, and at the beginning there were complaints that JSON was harder to use for that reason. The reason why JSON won rapidly even for backend apps which never loaded it in JSON was ergonomics: every part of the XML world from the parsers to XPath/XSLT/XQuery to the rat’s nest of standards was plagued by the hairy-shirt “this is hard and should feel hard” attitude that has thankfully become less common. I saw so many people just burn out in the entire ecosystem because they got tired of unhelpful errors, pointless usability bugs around namespaces, low-quality or missing examples, and especially how common tools just stopped getting improved.

I maintain that the format would have been far more popular if all of the effort spent on standards work after the turn of the century had been suspended and the time directed to fixing things like the usability of namespaces in almost every parser, and hiring at least one person to work on libxml2 so developers could actually use features which shipped after 1999. Unfortunately it seemed like there were a ton of architects who really wanted to spend time building castles in the air and they just seemed to assume that someone else would do the boring parts of implementing it, but those people all jumped on JSON pretty quickly. I worked with a bunch of people who weren’t developers and the cycle of initial enthusiasm fading into “doesn’t this kind of suck?” with XML was depressing to watch having seen so much initial promise.

Re: After 6 years, I'm over GraphQL

#590

Post by chuckadams »

pants2 wrote: post #426
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 '…

Buf Connect or any RPC design really is great. I'm sick of REST too. No more endless discussions about how to make this endpoint the most RESTful or how to cram a feature into REST that doesn't fit. "Oh you need an endpoint to hibernate the server? Just POST a new Hibernate object to the /api/v2/hibernations service." No. With RPC we can just make a HibernateServer call and be done with it.

RTF tried to make it clear in his famous dissertation that REST was about resource-oriented hypermedia, and that apps not designed around hypermedia should use different architectures -- he even names some of them. Unfortunately he inspired many followers to interpret it to mean that hypermedia is the One And Only True Way to design apps for the web.
Post reply on HN