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

41–50 of 721 posts

Re: After 6 years, I'm over GraphQL

#41

Post by graemep »

zer00eyz wrote: post #2

GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…

FB have a lot of resources to manage the complexity of this.

For most people "security is baked in to every field" is going to be very expensive.

Re: After 6 years, I'm over GraphQL

#42

Post by baq »

nesarkvechnep wrote: post #30

Whenever you see REST in the article, think RPC. The author even says REST is simpler than GraphQL but I suspect they hadn’t implemented a REST API… ever.

I’ve done it once in my two decades of being paid to code and only because it was small enough to not impact any timelines… nobody cared anyway. Otherwise REST now means ‘RPC over HTTP with JSON marshaling’ for better or worse.

Re: After 6 years, I'm over GraphQL

#43

Post by donatj »

For the service I primarily work on, we've stuck firmly with REST for our internal APIs despite some mild pressure from elsewhere in the company to move to GraphQL. I personally believe it's been the right choice. Not only would it be probably an order of magnitude more complicated to setup and maintain, our REST APIs already are very performant.

We've got little to gain, and the lack of flexibility from our POV is a relatively good thing. It gives us direct insight into desired use cases, and since the APIs are internal it lets us provide guidance on potentially better ways of implementing things as well as in some cases being able to provide direct optimizations for specific tasks.

Re: After 6 years, I'm over GraphQL

#45

Post by k__ »

9dev wrote: post #34
nesarkvechnep wrote: post #30

Whenever you see REST in the article, think RPC. The author even says REST is simpler than GraphQL but I suspect they hadn’t implemented a REST API… ever.

What is that you find so complex about RESTful APIs?

I assume, it's less about the complexity and more about most people not understanding REST.

Re: After 6 years, I'm over GraphQL

#46

Post by zer00eyz »

graemep wrote: post #41
zer00eyz wrote: post #2

GraphQL is the peanut butter to Reacts chocolate at FB. It works there because 1. Every user is logged in. Is there anything you can do at FB without giving up something to the Zuck? 2. Because it's all behind a login, you can front load the first login/request with a giant SPA and then run all the custom queries you want. 3. everything at FB is some sort of blended context (my user, someone else's user, a permission…

FB have a lot of resources to manage the complexity of this. For most people "security is baked in to every field" is going to be very expensive.

Candidly, I think a lot of the "security" is baked into the data model of what FB is... Are we linked on the graph, are we linked directly, what do your permissions allow me to do based on that relationship. It isn't a difficult query to wrap most requests in. I dont think FB needs that many people keeping an eye on this.

That having been said, outside that data model, your absolutely correct that its going to be costly to maintain those extra layers of relationships.

Re: After 6 years, I'm over GraphQL

#47

Post by DanielHB »

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…

GraphQL is very good for places where frontend and backend developers are isolated from each other (separate teams). Or rather places where you have data-producers and data-consumers as separate teams. If you have a big enough org eventually there will be many of such teams, interdisciplinary teams are not feasible at scale for everything.

It allows teams to work with less communication overhead. It solves more of a human problems than a technical problems, if someone think there is no value in that and bare metal performance is paramount that person never worked in a big org.

> RPC and REST are just more straightforward to monitor, log, cache, authorize and debug.

In some ways yes, in others no. For example it can be near impossible to see if a deprecated field in a REST API is still being used and by which clients it is being used. With GraphQL this is fairly simple.

Unfortunately GraphQL way of working is very different from normal REST APIs and often requires more complex server-side caching. The N+1 problem needs to be figured out upfront for every data-storage system used in the backend.

Re: After 6 years, I'm over GraphQL

#49

Post by cqqxo4zV46cp »

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 team “I have a plethora of use-specific endpoints”, and who here is on team “I built dynamic field selection and relationship traversal into API framework”? And, yeah. Dealing with N+1 database queries is loads easier if you constrain the potential pathways to the point that you can just hard-code your database optimisations instead of having to build a dynamic query optimiser. So you end up with a bunch of basic resource-mirror endpoints and then the N+1 database queries become N+1 HTTP requests. But hey, at least the requests are roughly equally expensive so you can simplify your rate limiting! As usual, it’s a question of trade offs, and it’s not the easy-path “you aren’t Facebook, so you don’t need it!” that people throw around here on the reg’. And, certainly, those that look down their nose and say “I know that I was right to not care for this, bloody magpie developers and their shiny toys” are certainly speaking with a misplaced sense of superiority.

Re: After 6 years, I'm over GraphQL

#50

Post by jvans »

Additional graph pain points I'd add:

Reliability:

* Not null fields in a distributed system are a lie. Clients write code assuming something is not null, so a query that fetches data from N sub systems breaks the entire page when one of them fails.

Performance:

* People say you only need to fetch just what the page wants but in practice clients create re-usable fragments for every object in the system and use it everywhere. Any time a new field is added, every api call fetches that new field adding latency everywhere

* clients are unaware of the underlying topology and add fields that are usually harmless but have bad tail latencies.

* The completely generic nature of the API means the backend can't optimize performance for a specific page. E.g. if one API has nasty tails, but it's not that important for this page, the backend could time it out at some reasonable value instead of holding up the entire request

Post reply on HN