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

171–180 of 721 posts

Re: After 6 years, I'm over GraphQL

#171

Post by barrkel »

BiteCode_dev wrote: post #106
tomrod wrote: post #101

Earlier quoted context omitted.

I haven't done much more than toy projects in GraphQL. Is there no way to limit the query complexity/cost? Such as a statement timeout in postgres?

Ah but that's the beauty of GraphQL, a query can actually fetch data from several systems: the db, the cache, the search engine, etc. It's all abstracted away. But let's say you have a timeout, and they have a retry, then suddenly, your server is now spammed by all the clients retry again and again a query that worked a week ago, but today is too heavy because of a tiny change nobody noticed. And even if it's not the…

To be clear, the main thing that's abstracted away are server round-trips and client-side joins. REST APIs can fetch data from different systems too.

Re: After 6 years, I'm over GraphQL

#172

Post by hansonkd »

I never understood peoples positions that GraphQL all of the sudden the frontend can make any Query it wants and control is out of the hands of the backend. That seems orthogonal to my experiences with GraphQL.

GraphQL is a protocol and you define the implementation. Some GraphQL implementations like REST implementations try to generate everything for you. That is not "GraphQL" but one type.

GraphQL is way to query nested APIS. The dataloading N+1 Problems are substantially easier to solve in GraphQL and many frameworks have solutions auto-optimize ORM queries for example.

The backend defines the query, the frontend requests it. Simple. Never understood the hate against GQL that now the frontend has all this power. They have exactly as much power as you would have exposed in a Rest Interface just now the backend can actually see all the data it needs at once and optimize.

If you are worried about a cartesian product from a GraphQL call I have news for you about production REST systems. Ever seen an engineer do a loop and make n+1 REST calls for resources? It happens more often then you think.

REST encourages resource waste. You are getting fields you don't need. Hard to query related objects, etc.

Benefits I have reaped with GraphQL:

  1. API analysis - I can statically analyze a typescript program and verify their API calls are valid against backend schema.
  2. Usage analysis - Statically analyzing the schema I can see which fields are still in use and safely refactor.
  3. Frontend Velocity - The frontend can cange its data needs on the frontend query whatever related objects it needs efficiently without backend changes. You can get all data for a page with 1 call and not have to have page specific endpoints.
  4. Less backend engineers are needed as API changes less.
  5. N+1 Optimization much easier to solve in GraphQL then REST
There are so many advantages to using GraphQL. The only advantage of REST I can think of is for static external APIs.

Re: After 6 years, I'm over GraphQL

#173

Post by ctvo »

BiteCode_dev wrote: post #162
ctvo wrote: post #146

Earlier quoted context omitted.

> React was a blessing for the few creating apps that needed more than jquery, and that AngularJS 1 couldn't handle for perfs reason. performance was the least attractive reason for adopting React. React introduced composition as the default way of thinking about UIs to the web. You created components and used them to build more complex components. Data was immutable and flowed in one direction (parent component -> c…

The simple fact you say > React has always had good documentation Tells me you rewrite the entire history. In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world. At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial. And by the way, we h…

You know you can just check before making these claims. It helps with credibility.

> In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world.

React's original documentation site from June of 2013 (when React was first introduced):

https://web.archive.org/web/20130607085014/http://facebook.g...

> JSX is a JavaScript XML syntax transform recommended (but not required) for use with React.

It goes on to explain exactly what JSX is and how it converts to JS functions. Feel free to click around that original documentation site.

Here's the README.md from the commit at the same time:

https://github.com/facebook/react/tree/a41aa76ef36471ba07b29...

> You'll notice that we used an XML-like syntax; we call it JSX. JSX is not required to use React, but it makes code more readable, and writing it feels like writing HTML. A simple transform is included with React that allows converting JSX into native JavaScript for browsers to digest.

At this point I would kindly ask you to go away.

Re: After 6 years, I'm over GraphQL

#174

Post by theK »

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 we gone with more powerful standards like API blueprint (or maybe raml).

Case in point, I'm consulting an org with roughly 1k engineers right now on improving their API ecosystem and what we are seeing is that the more OpenAPI tooling they use, the worse the DX gets...

Re: After 6 years, I'm over GraphQL

#175

Post by dumbo-octopus »

UweSchmidt wrote: post #18
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…

What if Facebook wanted to open up parts of the site for users without an account, would that require a major reengineering? I've wondered why Facebook (and Instagram) are so strict about not showing anything to logged-out users, could technical reasons be part of that decision?

Are they? I have full access to all the Instagram reels, posts, comments, etc. friends send me, without being logged in.

Re: After 6 years, I'm over GraphQL

#176

Post by BiteCode_dev »

ctvo wrote: post #173
BiteCode_dev wrote: post #162

Earlier quoted context omitted.

The simple fact you say > React has always had good documentation Tells me you rewrite the entire history. In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world. At this stage it's not "superficial understanding of the space" this kind of comment is guilty of, it's total denial. And by the way, we h…

You know you can just check before making these claims. It helps with credibility. > In fact, for years, react didn't even tell in the doc you could use it without a transpiler so people had to learn a whole build chain before even getting to the hello world. React's original documentation site from June of 2013 (when React was first introduced): https://web.archive.org/web/20130607085014/http://facebook.g... > JSX i…

I stand corrected, I'm the one with a distorted memory of the doc.

Re: After 6 years, I'm over GraphQL

#177

Post by hansonkd »

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…

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 about structuring REST calls but those aren't going to cause any real forward progress for the industry and are inconsequential when it comes to business outcomes.

You could argue almost any tech solution in a non-pure tech play is largely in consequentially as long as the end goal of the org is met, but managing REST APIS were a huge point of friction at past companies.

Either it goes through a long review process to make sure things are structured "right" (ie lots of opinions that nobody can sync on) or people just throw up rest endpoints willynilly until you have no idea what to use.

GraphQL is essentially the "Black" for Python Syntax but for Web APIs. Ever seen engineers fight over spaces vs tabs, 8 vs 4 spaces, whether a space before a colon? those fights happened a lot and then `black` came out and standardized it so there was nothing to fight over.

GraphqL makes things very clear and standard, but can't please everyone.

Re: After 6 years, I'm over GraphQL

#178

Post by TheSoftwareGuy »

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…

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

Re: After 6 years, I'm over GraphQL

#179

Post by foobarian »

danielheath wrote: post #103
RHSeeger wrote: post #89

Earlier quoted context omitted.

Can you explain what you mean by this? The GraphQL API you expose allows only a certain schema. Sure, callers can craft a request that is slow because it's asking for too much, but - Each individual thing available in the request should be no less timely to handle than it would via any other api - Combining too many things together in a single call isn't a failing of the GraphQL endpoint, it's a failing of the caller…

The problem is that the client team can - without notice - change their query patterns in a way that creates excess load when deployed. When you use the "REST" / JSON-over-HTTP pattern which was more common in 2010, changes in query patterns necessarily involve the backend team, which means they are aware of the change & have an opportunity to get ahead of any performance impact.

> changes in query patterns necessarily involve the backend team,

How does this follow? A client team can decide to e.g. put up a cross-sell shelf on a low-traffic page by calling a REST endpoint with tons of details and you have the same problem. I don't see the difference in any of these discussions, the only thing different is the schema syntax (graphql vs. openapi)

Re: After 6 years, I'm over GraphQL

#180

Post by azangru »

diggan wrote: post #158
azangru wrote: post #124

Earlier quoted context omitted.

Performance. Alex Russell, formerly of Google and now the product owner of Microsoft Edge loves to rant about it. His latest rant is how Edge has significantly improved the performance of some of its UI features by moving off React [0]. [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste...

> [0] https://blogs.windows.com/msedgedev/2024/05/28/an-even-faste... Maybe I'm missing something obvious, but React isn't mentioned in that post. Maybe you put the wrong URL?

Odd, I thought I saw something about React in Microsoft's communications as well. Anyway, here is the horse's mouth: https://toot.cafe/@slightlyoff/112521248529973776
Post reply on HN