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

451–460 of 721 posts

Re: After 6 years, I'm over GraphQL

#451

Post by culi »

RedShift1 wrote: post #81
brabel wrote: post #78

Earlier quoted context omitted.

Our frontend team needs to show the whole thing every time (as the user sees and edits full resources in most cases), which means they MUST keep a full query representing the entire resource, and when we add stuff in the backend, they must also add those things in the frontend (as they cannot generate UI for new things in most occasions). GraphQL was really a mistake for us.

Why is this a problem? If you add fields on a REST endpoint, you're going to have to change the client too to deal with those new fields.

it sounds like they are just dumping every field to somehow show the user without any validation/specific rendering logic for each field

Re: After 6 years, I'm over GraphQL

#452

Post by int_19h »

WorldMaker wrote: post #389
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…

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/

This is more of a concern for JSON configs and other such uses that are directly exposed to humans, but not really for machine-generated and machine-consumed data.

Re: After 6 years, I'm over GraphQL

#453

Post by nfw2 »

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…

Whitelisting the queries that clients can use in prod actually doesn't seem like a bad option to avoid a lot of these security issues, assuming you control the clients

Re: After 6 years, I'm over GraphQL

#454

Post by andrewingram »

smaudet wrote: post #248
strken wrote: post #121

Earlier quoted context omitted.

I'm not sure this is any more or less of a problem for REST APIs. What if your engineers change $client/$server and the new version makes really expensive queries? Well, ask them not to do that, then when some of them inevitably ignore you, start to review their code, terminate long-running queries, batch or pool fanouts so they don't take anything down, monitor new releases and roll back if anything breaks, etc. If…

> What if your engineers change $client/$server and the new version makes really expensive queries? Yes, so the cost benefit here is not in favor of GraphQL. If both technologies ultimately suffer from the same issues (what to do about unpredictable clients), but one is far more complex to implement and use (GraphQL), then there's a clear winner. Spoiler, its not GraphQL. Page specific endpoints, I would argue, can d…

When you build a GraphQL server, you’re creating a system that outputs page-specific endpoints. They can be generated just-in-time (the default) or at build time (the general recommendation).

The engineering work involved shifts from building individual endpoints to building the endpoint factory. This shift may or may not be worth the trade off, but there are definite advantages, especially from the perspective of whomever is building the client. And once you factor in the ease at which you can introduce partial streaming with defer and streamable (granted they’re still WIP spec-wise), the experience can be pretty sublime.

Re: After 6 years, I'm over GraphQL

#455

Post by teaearlgraycold »

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…

I think a lot of people like GraphQL because it provides strongly typed API interfaces. But I've been able to hack together a better REST alternative in full-stack typescript codebases. And my solution doesn't need to compile any kind of client or intermediary.

Re: After 6 years, I'm over GraphQL

#456

Post by culi »

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 '…

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 complex or too nested "you're doing it wrong™"

Re: After 6 years, I'm over GraphQL

#457

Post by int_19h »

jayd16 wrote: post #433
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…

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 their own implementations, although in some cases it took a while - e.g. for .NET you had to use third-party libraries until 2019.

Re: After 6 years, I'm over GraphQL

#458

Post by int_19h »

foobarian wrote: post #179
danielheath wrote: post #103

Earlier quoted context omitted.

The problem is that the client team can - without notice - change their query patterns in a way that creates excess load when deployed. When you use the "REST" / JSON-over-HTTP pattern which was more common in 2010, changes in query patterns necessarily involve the backend team, which means they are aware of the change & have an opportunity to get ahead of any performance impact.

> changes in query patterns necessarily involve the backend team, How does this follow? A client team can decide to e.g. put up a cross-sell shelf on a low-traffic page by calling a REST endpoint with tons of details and you have the same problem. I don't see the difference in any of these discussions, the only thing different is the schema syntax (graphql vs. openapi)

GQL is far more flexible wrt what kind of queries it can do (and yes, it can be constrained, but this flexibility is the whole point). Which means that turning a cheap query into an expensive one accidentally is very easy.

A hand-coded REST endpoint will give you a bunch of predefined options for filtering, sorting etc, and the dev who implements it will generally assume that all of those can be used, and write the backing query (and create indices) accordingly.

Re: After 6 years, I'm over GraphQL

#459

Post by rglover »

sswaner wrote: post #55
FrustratedMonky wrote: post #39

Earlier quoted context omitted.

Curious, I hadn't heard that take on Mongo. Do you have a link to some more info on this.

https://youtu.be/b2F-DItXtZs?si=rxrMwJVu95WQQt7M

It's a shame that this out of date/meme stuff continues to give MongoDB a bad rap. It's a great DB if you need to be flexible/move fast and avoid migration headaches (speaking first hand, this has dragged dev cycles quite a bit). Most startups/saas/web apps would benefit greatly from using MongoDB purely from a reduction of complexity standpoint.

The current version of MongoDB, imo, makes you super productive and scales without a ton of thinking. If you're working in Node.js, it's even more useful as the query language works just like a JS/JSON object so writing queries is super fast (compared to SQL where you have to spend a lot of mental cycles figuring out how to map object/array data).

I've found that denormalizing data (not even necessarily copying/duping data, but trying to centralize storage of it) when using MongoDB is the way to get the most value out of it. If you try to treat it like an RDB (which does work but can cause issues with complex queries), you'll run into headaches. If you just design stuff to be nested, though (and use the built-in APIs to query that nested data), it works incredibly well.

Re: After 6 years, I'm over GraphQL

#460

Post by Xarodon »

cess11 wrote: post #276
mattbrewsbytes wrote: post #140

Earlier quoted context omitted.

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug. REST API's are a proven solution for the problem of other apps, including front-ends, needing data from a data store. Using JSON is much improved over the days of XML and SOAP. Beyond that there haven't been advancements in technology that cause fundamental shifts in that problem space. There have been different opinions about s…

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…

XML parsers suffer the same fragmentation issues that JSON parsers do.

Go's XML parser straight-up emits broken XML when trying to output tags that have prefixed namespaces.

Post reply on HN