After 6 years, I'm over GraphQL • Hacker News Board

Re: After 6 years, I'm over GraphQL

#231

Post by hansonkd » Thu, May 30, 2024, 2:51 PM UTC

theptip wrote: post #228

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…

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

Re: After 6 years, I'm over GraphQL

#232

Post by karmakaze » Thu, May 30, 2024, 2:52 PM UTC

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…

One place I was at we used REST with a hydration service that ran as a proxy in front of the requests. That gave us most of the benefits of GraphQL and we only implemented it for the main resources (users, photos, and maybe one other thing). To minimize latency/faults the hydration service ran locally on every webapp/API server. I wasn't around for far too long after though to see how it turned out as it grew (if it did at all, the company sort-of went defunct--development-wise anyway).

I also recall, we had similar N+1 query problems in the REST API endpoints irrespective of hydrating the returned resources.

The biggest benefit of GraphQL I can see from a user perspective is that it lowers total latency especially on mobile with fewer round trips.

Re: After 6 years, I'm over GraphQL

#233

Post by realusername » Thu, May 30, 2024, 2:52 PM UTC

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…

> With internal REST for companies I have seen so many single page specific endpoints. Gross.

Single page endpoints is exactly what you want if you have more than 5 engineers in your company anyways.

It ensures that the endpoints are maintainable and future-proof when people are working on different features.

Re: After 6 years, I'm over GraphQL

#234

Post by Calamitous » Thu, May 30, 2024, 2:54 PM UTC

Fundamentally, GraphQL is a _query language_, but people keep trying to build/use it as an _API_.

Re: After 6 years, I'm over GraphQL

#235

Post by tossandthrow » Thu, May 30, 2024, 2:55 PM UTC

eatsyourtacos wrote: post #230

I only have one experience with a client using GraphQL and it was horrendous . My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that…

You should have looked at the schema.

It indeed seems like GraphQL saved your client in this case.

Re: After 6 years, I'm over GraphQL

#236

Post by petesergeant » Thu, May 30, 2024, 2:57 PM UTC

foobarian wrote: post #189

lpapez wrote: post #25

Kudos to the author for reevaluating his opinion and changing heart on a technology he admits to have championed before. IMO GraphQL is a technological dead end in much the same way as Mongo is. They were both conceived to solve a perceived problem with tools widely adopted at the time, but ended up with something which is even worse, while the tools they were trying to replace rapidly matured and improved. Today Ope…

> IMO GraphQL is a technological dead end in much the same way as Mongo is. Can you suggest alternatives to graph introspection and related UI tools like GraphiQL, and the subgraph federation systems?

What are the use-cases for graph introspection in any but a tiny fraction of cases?

Re: After 6 years, I'm over GraphQL

#237

Post by mgkimsal » Thu, May 30, 2024, 2:57 PM UTC

datavirtue wrote: post #224

kiney wrote: post #196

Earlier quoted context omitted.

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

Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.

You are literally Transferring the REpresented State of a given page/view/screen.

Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.

Re: After 6 years, I'm over GraphQL

#238

Post by tossandthrow » Thu, May 30, 2024, 2:57 PM UTC

chasd00 wrote: post #151

RedShift1 wrote: post #81

Earlier quoted context omitted.

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.

If new fields show up in a json response just ignore them. Why would you need to change the client if new fields show up in the response?

Indeed, this is what graphQL solves.

Are you proposing just to add new field to a JSON response, even though they are not needed?

Re: After 6 years, I'm over GraphQL

#239

Post by steve_adams_86 » Thu, May 30, 2024, 2:57 PM UTC

eatsyourtacos wrote: post #230

I only have one experience with a client using GraphQL and it was horrendous . My biggest complain is there seemed to be no way to just to query all fields. I know that is intentional and the point of GraphQL.. but they should support something for the server side to enable this. Maybe they have over the years, I don't know. But my experience was during the implementation phase the client kept adding new fields that…

I think you’re right about it being suited to well-defined scenarios. But I agree too that a regular endpoint to get specific data is more often than not totally acceptable. I’m not aware of many situations where the flexibility of graphql is as useful or important as the demands it places on a team.

I worked on a team where 3 of us were well into our second decade of software development, yet we still had a consultant come in to help us sanity check our graphql implementations and ongoing strategy.

We were mostly on the right track. The struggles we were having were just… Normal.

At that point I really lost steam. Prior to that I was motivated by the thought that something wasn’t clicking yet. Discovering that I understood graphql just fine but it was typically a bad developer experience with obtuse tooling and queries took the wind out of the sails.

The worst part was mutations.

Writing graphql handlers in Rust was also awful. The more you try to leverage the flexibility of graphql, the more Rust freaks out because you’re doing exactly what you shouldn’t in such a strict environment.

Yet… Doing this in a language with weaker typing and less strictness seems like a potential minefield of bugs.

I see the appeal of graphql and I’ve liked it in small one-off situations where it was useful but had limited scope. Otherwise I genuinely hope I don’t work with it again.

Re: After 6 years, I'm over GraphQL

#240

Post by WD-42 » Thu, May 30, 2024, 2:57 PM UTC

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

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.