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

211–220 of 721 posts

Re: After 6 years, I'm over GraphQL

#211

Post by hansonkd »

jerf wrote: post #155
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…

There's a lot of relevant differences between REST & GraphQL. It is possible to construct a REST endpoint that simply can't do any of those things, and such construction is a mid-level developer task at best. For instance, pagination of "all posts ever" is not uncommon, and clients won't be shocked to deal with it. GraphQL is enough harder to characterize the performance of that it definitely qualifies as a change in…

This is Wrong.

GraphQL only exposes what you ask it to. There are plenty of pagination plugins for GraphQL frameworks just as there are plugins to REST framework.

GraphQL can be restrictive as REST if you want it to be.

The point is GraphQL can be "as restrictive" as REST, but if you want to enable more efficient queries by knowing all the data that the frontend is requesting, you can. But the opposite isn't true of REST. With REST if you want more advanced functionality like that you have to define your own specification.

Re: After 6 years, I'm over GraphQL

#212

Post by sixdimensional »

strken wrote: post #121
BiteCode_dev wrote: post #92

Earlier quoted context omitted.

The problem is you delegate a lot of the query building to the client, hoping that it will not suddenly change your performance profile by being creative and that you will have not missed an obviously expensive use case coming. That's a huge bet, especially given that GraphQL is expensive in the first place, and given that the more you grow the API in size, the less you can actually map the cartesian product of all r…

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…

Even a SQL query can suffer the same fate. Ever tried writing a SQL query against a distributed database that isn’t optimized for that read path?

I think that’s what’s really pointing out the root cause issues here, it’s not purely GraphQL’s problem, it’s the problems inherent to distributed systems.

Re: After 6 years, I'm over GraphQL

#213

Post by nurple »

kiney wrote: post #196
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…

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

I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.

Re: After 6 years, I'm over GraphQL

#214

Post by clintonb11 »

hansonkd wrote: post #193
barrkel wrote: post #168

Earlier quoted context omitted.

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

I think the point here is, if you have to involve a backend team to add restrictions to the graphql endpoints and try to make good educated guesses where those might be, then the idea of frontend not needing backend engineers to query whatever they need becomes less of an advantage. So is the complexity of setting up graphql and then having your backend team try and make sure no frontend engineers can do terrible queries better for the software than custom rest APIs where needed and standard resource APIs everywhere else. Obviously it depends on the project. But I find the complexity of setting up and managing graphql often isn’t worth the pain, especially with schema first resource api designs and tooling like Google’s AIP linter.

Re: After 6 years, I'm over GraphQL

#215

Post by presentation »

I’ve found success just using GraphQL internally (with tools like Hasura or Postgraphile + row level security done strategically) and not exposing it directly externally. That way you can trust the clients and it unblocks frontend devs to accomplish what they need.

Re: After 6 years, I'm over GraphQL

#216

Post by theK »

tommica wrote: post #185
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…

> I find it a bit poor though that the only recommended alternative is OpenAPI rest APIs. What are your recommendations? gRpc?

My rant, as evident after that sentence, is about the industry selecting to standardize on Swagger instead of emerging a more powerful/succinct/etc system.

Re: After 6 years, I'm over GraphQL

#217

Post by raxxorraxor »

mattbrewsbytes wrote: post #140
atsjie wrote: post #24

Worked on two GraphQL projects; I was quickly cured from the hype. I recognize a lot of points in this article. In both these projects the GraphQL had started small. I came in during a more mature phase of these projects (2 and 4 years). That's where the requirements are harder, more specific, and overall complexity has grown. Adoption and demand on the API were growing quickly. Hence you logically spend more time de…

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

XML still has its usage and is excellent to quickly validate documents, but JSON clearly won in this use case because it was kept simple, stupid.

Re: After 6 years, I'm over GraphQL

#218

Post by toastercat »

gatvol wrote: post #51
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…

If you're writing you're REST API by hand I'd suggest that you may not be doing it optimally.

How should you write your REST API?

Re: After 6 years, I'm over GraphQL

#219

Post by clintonb11 »

jpalawaga wrote: post #153
DanielHB wrote: post #116

Earlier quoted context omitted.

> It is far better for the Backend to provide Frontend a contract It sure is better for the backend team, but the client teams will need to have countless meetings begging to establish/change a contract and always being told it will come in the next sprint (or the one after, or in Q3). > This leads to far more fingerpointing/inefficiency in the log run, despite whatever illusion of short-term expediency it creates. I…

trying to solve org problems with tech just creates more problems, allthewhile not actually solving the original problem.

This is what I wanted to say too. If your backend team is incapable of rapidly adding new endpoints for you, they probably are going to create a crappy graphql experience and not solve those problems either. So many frontend engineers on here saying that graphql solves the problem they had with backend engineers not being responsive or slow, but that is an org problem, not a technology problem.

Re: After 6 years, I'm over GraphQL

#220

Post by hansonkd »

clintonb11 wrote: post #207
hansonkd wrote: post #197

Earlier quoted context omitted.

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.

Is the flexibility worth the tradeoffs? Maybe in a company where you are adding new pages all the time with deeply nested relational data needs. But I would argue this is more rare than not. And I often find that frontend engineers aren’t as familiar with database queries and the load they are putting on the system with some of the graphql queries they are making. Flexibility for frontend has its own tradeoffs and I…

Sorry what are the tradeoffs?

I'm not sure where this narrative comes from that GraphQL immediately means that the frontend time will have no idea what they are doing and will induce load on the system.

95% of my nested graphql fields are based on foreign key indexes so its almost no additional load to the system (only 1 query per "level" of GraphQL) to query the nested objects.

I restrict GraphQL to 5 levels and now I have 5 queries per API call instead of 5 Queries over 5 API calls.

The backend team exposes the fields that they know are efficient to query. They can restrict the depth of the GraphQL, number of fields, etc.

Post reply on HN