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

191–200 of 721 posts

Re: After 6 years, I'm over GraphQL

#191

Post by WiseWeasel »

travellingprog wrote: post #128
probabletrain wrote: post #85

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated,…

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

Except it only has a query-based cache, rather than a normalized cache by type name and ID. This means a deeply nested component running a mutation to update an entity can’t update the state of a component a few levels up purely with the response to that mutation, it instead needs to invalidate the cache and cause the parent to requery, much less performant.

Re: After 6 years, I'm over GraphQL

#193

Post by hansonkd »

barrkel wrote: post #168
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…

If you have separation between front and back end, then the back end team can elect to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level. Thing get more problematic when there's vertical ownership for a feature, where the UI needs just a few extra things and you end up with a REST response which is fa…

> the back end team can select to serve REST APIs which only permit selecting, filtering, grouping and pagination that they know they can support within defined latency bounds for a given traffic level.

Why do you think that they can't do that with GraphQL? GraphQL isn't open ended. Its a highly restricted syntax for calling nested resources. If a resource is expensive simply don't nest it and make it a top level field and it is the same as REST?

Lots of nested resources are by default efficiently served by GraphQL because they are mostly returning single object foreign keys. Something that would take extra calls with REST.

GraphQL can have the same restrictions and performance guarantees as REST but the later is not necessarily true because in REST there is no standard way to define nested resource access.

Re: After 6 years, I'm over GraphQL

#194

Post by dventimi »

doctor_eval wrote: post #135
RedShift1 wrote: post #28

I still love GraphQL, but much of the love comes from using tools like PostGraphile which generates the API for you based on your database schema. I then add my own Javascript plugins as necessary. Going back to REST and hand writing everything gives me the shivers, how much time am I spending just translating data A to data B? Authorization: I do it in the database using roles, row level security and column level se…

Agree with this 100%, Postgraphile is awesome. I started a new project recently and was writing “REST” APIs because I’d been reading that people were put off by GraphQL, but it was a complete pain - instead of exposing my data and querying it as needed, I had to try to guess up front what I should expose in what object. It was the bad old days all over again, writing adhoc code on the server to meet the needs of the…

I think some of the complaints come from using code to offer GraphQL backends rather than just using PostGraphile

Re: After 6 years, I'm over GraphQL

#195

Post by ComputerGuru »

foobarian wrote: post #186
theK wrote: post #174

Fine article describing the weak points of GrahQL. I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. I have no beef against doing REST, jsonRPC etc. Actually I consistently steer people that way. But the documentation format we chose as an industry to build these things with, Swagger, is just disappointing. Some times I think the industry would be at a totally different point had…

> But the documentation format we chose as an industry to build these things with, Swagger This right here is IMO the biggest advantage of a GraphQL system. What equivalent to GraphiQL is there for OpenAPI? With GraphQL my frontend devs can go shopping for data in one UI, with rich descriptions and strong typing and even try out the queries live.

You are summarizing the very reason for its existence and popularity: everything is about making the frontend dev’s job easier, at any cost. This is a common theme across the entire web-adjacent industry and has been responsible for plenty of misguided changes and choices.

Re: After 6 years, I'm over GraphQL

#196

Post by kiney »

hansonkd wrote: post #177
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…

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

Re: After 6 years, I'm over GraphQL

#197

Post by hansonkd »

ComputerGuru wrote: post #188
hansonkd wrote: post #177

Earlier quoted context omitted.

REST APIS suck for nested resources. GraphQL is a huge breakthrough in managing them. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think because they don't want to have to create a backend ticket to add related resources to a call. With internal REST for companies I have seen so many single page specific endpoints. Gross. > There have been different opinions ab…

> With internal REST for companies I have seen so many single page specific endpoints. Gross. Hardly gross. It is what it is and it’s universal across the domain. I bet Windows has internal APIs or even external ones that were created just for one page/widget/dialog of one app. It’s the nature of things at times.

Its gross because it is a waste.

An engineer had to spend time to make that specific API for that page instead of the frontend consumer using what was already defined and get all the resources with one call and 0 backend engineer needed for that new page.

Re: After 6 years, I'm over GraphQL

#198

Post by dventimi »

nprateem wrote: post #110

I'm surprised it took 6 years to discover these issues. The N+1 problem and auth/field privacy are obvious on practically any project. In other news, bitcoin will never replace cash, most companies don't need k8s and AGI isn't 2 years away.

The N+1 problem doesn't exist on any project that uses, say, Hasura.

Re: After 6 years, I'm over GraphQL

#199

Post by casperb »

I like restful API’s the most. Graphql is cool if you need data combined that is not nicely available in the restful endpoints. But I think that could mostly be solved with good endpoints that help with the actual use cases. When restful endpoints are hard to use, in a lot of cases it is because they are to much focused on how it is easy to write server side, then it is to consume them.

Re: After 6 years, I'm over GraphQL

#200

Post by dventimi »

cqqxo4zV46cp wrote: post #49

So, TL;DR: if you want to exploit the flexibility offered by GraphQL, you need to pay for that with implantation complexity. I’ve never used GraphQL in my life yet can foresee the issues described in this post. If you try to retrofit GraphQL feature X, Y, or Z into your REST API, you’ll run into these exact same problems. If you stick with a classic REST API, you pay for that simplicity in other ways. Who here is on…

Not necessarily. Tools like Hasura, PostGraphile, and Prisma let you skip out without even having to pay with implementation complexity.
Post reply on HN