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

221–230 of 721 posts

Re: After 6 years, I'm over GraphQL

#221

Post by nurple »

TheSoftwareGuy wrote: post #178
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…

I think us engineers have an inherent desire to try to innovate, and I think that is a good thing. Some problems will require a lot of wrong turns before finding the right path, but that is simply the nature of innovation

Agreed it's a good thing. Writing software today is still a slog that turns into a spaghetti bowl without focused intent by highly skilled devs. I think most devs realize this and really want there to be something better, and the only way to find something good is to find a lot of the bad around it first.

I like the thought experiment of adding a new persisted/editable field to an entity in a web app, if you've done full-stack you know all the layers that need to be touched to accomplish this and how lame most of the work turns out to be. After doing that 20 times while iterating, any dev worth their salt starts to wonder why it sucks so bad still and how it could be made better, and some will actually try.

Re: After 6 years, I'm over GraphQL

#222

Post by pavel_lishin »

hansonkd wrote: post #197
ComputerGuru wrote: post #188

Earlier quoted context omitted.

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

On the other hand, it may take that engineer less time to create a page-specific endpoint than it would be to create something more generic that might serve other purposes (that may never come to pass), which may also involve talking to other teams, checking what future plans are, etc.

And that's assuming it's a new endpoint; if there's an existing endpoint that does almost what's necessary, they may need to check in with that team about what modifications to the endpoint would be acceptable, etc.

Single-page endpoints aren't great, but often times they're acceptable because they end up being a half-day task instead of a week-long slog.

Re: After 6 years, I'm over GraphQL

#223

Post by flashgordon »

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…

>> Fun fact; in both these projects the original devs who set it up were no longer involved. Probably spreading their evangalism further elsewhere.

Ah this brings up bitter memories. Team I was managing was roped in to become the first graphql framework (nay platform) the ivory tower (central architecture run by the cto) team was building and trying to shove down the rest of the company. This was during the graphql craze around 5 years ago. The principal engineer leading it was even preemptively promoted to distinguished engineer for future contributions.

Fast-forward 5 years project was disbanded due to massive migration, cost and complexity problems. DE still lauded for experimentation heroism and evangelism. I think he is now pushing the latest flavors of the month to go for the next promo!

Re: After 6 years, I'm over GraphQL

#224

Post by datavirtue »

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

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.

Re: After 6 years, I'm over GraphQL

#225

Post by mst »

dventimi wrote: post #142
mst wrote: post #107

Earlier quoted context omitted.

Seems like at that point exposing each query as an OpenAPI endpoint would achieve pretty much the same thing. Then again having GraphQL as the definition for them is probably still not bad, I'll just have to write something that converts them to SQL::Abstract 2 trees once I get around to porting it to TS.

It would be the same thing except with Benje's approach, you're basically using GraphQL as a developer tool to create those end points instead of writing code to do it. And you don't have to write something to convert them to SQL if you're using PostgreSQL, because Benje's already written it for you.

postgraphile does look like it'll handle basic cases pretty nicely but I've gone through the docs and didn't find anything like an explanation of what SQL queries it ends up mapping to - do you happen to know if there's one I missed, or a list of examples of GraphQL + corresponding SQL, or something?

Re: After 6 years, I'm over GraphQL

#226

Post by datavirtue »

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.

It's analogous to a specific method in code. No idea why people go nuts over this.

Re: After 6 years, I'm over GraphQL

#227

Post by hansonkd »

clintonb11 wrote: post #214
hansonkd wrote: post #193

Earlier quoted context omitted.

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

> 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

No because if you dont do that you have to involve more engineers anyways to build the REST endpoints and keep modifying the rest endpoints.

GraphQL is also default restrictive (i.e. exposes nothing). You don't need to add engineers to make it restrictive.

In Startups typically:

  -> Frontend changes most frequently
  -> Backend "utility functions " changes less
  -> Data model changes the least
Without Graphql your "backend" ends up needing to have a lot of work and changes because it is constantly needing to be updated to the needs of the most frequent changes happening on the frontend.

With GraphQL the only time you need to update the backend is when those "utility" functions change (i.e. 3rd party api calls, etc) or the data model changes.

So you end up needing substantially less backend engineers.

Re: After 6 years, I'm over GraphQL

#228

Post by theptip »

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…

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 is a better go-to for most usecases.

Re: After 6 years, I'm over GraphQL

#229

Post by pavel_lishin »

knlam wrote: post #208

Working with GraphQL over 6 years, I have seen (and created) many mistakes mentioned in the article. GraphQL is not great but it has worked well for me, you just need to adapt & change mindset to create better interface for your graphQL endpoint. For example, having nested queries more than 2 levels is a no go for me (just like having nested inheritance is basically anti pattern) Focus more on your interface. One way…

I don't think I understand how that change avoids the N+1 issue. It's still fetching all of that user's friends, no?

Re: After 6 years, I'm over GraphQL

#230

Post by eatsyourtacos »

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 didn't know about and then I had to constantly ask them for the fields because I thought I was missing data. If I could have just queried ALL the fields, then saw what came in, and chop them down to what I need.. great.

The only way GraphQL seems to make any sense is if everything is basically completely defined and you are at a final project stage. After many many years of experience... this is rarely the case.

Cool piece of technology? Sure.. but hardly practical except in scenarios of extreme amounts of data and only when it makes sense for the client to return specific fields.

Although I think still for 95% of even those extreme cases, you just write a REST endpoint that returns the fields that make sense for the query....

Post reply on HN