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

131–140 of 721 posts

Re: After 6 years, I'm over GraphQL

#131

Post by doctor_eval »

dgb23 wrote: post #69

One of the major issues I have with GraphQL from the get go is that it introduces it's own syntax instead of using a commonly understood and established _data_ format like JSON or similar. Same problem with Prisma Model definitions and other such things. Please, if you make a new thing and it fits neatly into a data format, use a data format! Let me use all of those well established libraries, schema definitions and…

What do you mean? Both GraphQL queries and results are JSON. The query expression is just a json string. Are you referring to the schema language?

Re: After 6 years, I'm over GraphQL

#132

Post by herpdyderp »

Jeema101 wrote: post #125
dzonga wrote: post #88

when will people learn - you're not Facebook, or will never likely reach facebook scale. Graphql, Relay, React were things etc made for Facebook at facebook scale i.e whether that's in terms of engineers, resources or actual tech problems. There's plenty of other sites / services that receive almost as close to FB properties in terms of traffic yet you never hear them pushing all those tools. Trading firms, Porn firm…

I think an aggravating factor in the software world (that's maybe not as prevalent in other fields), is that developers tend to want to use the latest and newest technologies, even if said technology is not really appropriate for the task. It looks good on your resume to say that you used the same technology Facebook uses - the ol' "resume driven development".

You also usually need to actually try out a new technology to know if it’s going to help you. Less “must use the latest tech” and more “let’s see if this latest tech is helpful”. Of course, both happen.

Re: After 6 years, I'm over GraphQL

#133

Post by hombre_fatal »

0-bad-secrotrs wrote: post #64

Aside from all the valid points listed in the blog I found out that the frontend engineers in my company save some queries in central library and reuse them even if they don't need all the field returned by this array just to save themselves the time they spend writing queries so they are basically using GraphQL as REST at the end and now we have the worst of both worlds.

The difference is that the client came up with its own data access patterns instead of having to rely on the server to design the exact endpoints that it needs.

Overfetching or not, that's a rather big difference.

Re: After 6 years, I'm over GraphQL

#134

Post by dventimi »

I generally agree and am likewise "over" GraphQL. Having said that, I disagree on some of the finer points.

First, some of these issues--authorization, security, N+1--can be mitigated by using something like Prisma, PostGraphile, or Hasura, instead of crafting GraphQL backends with code.

Second, there are gains to be made by compiling a GraphQL operation to a single operation in the underlying database's query language (e.g. SQL)--when that's possible--rather than by following the "resolver and data-loader" catechism.

Third, as I've written elsewhere recently, I think the N+1 problem is overblown. Not that it doesn't exist, but just that it only sometimes exists and usually isn't as bad as is often claimed. But again, this is eliminated by switching to a compiler approach anyway, so it's not worth making a federal case over it.

Despite all this, like I said I'm still over GraphQL. If you must implement it, try to use one of the tools mentioned above if you can.

Re: After 6 years, I'm over GraphQL

#135

Post by doctor_eval »

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…

Agree with this 100%, Postgraphile is awesome. I started a new project recently and was writing “REST” APIs because I’d been reading that people were put off by GraphQL, but it was a complete pain - instead of exposing my data and querying it as needed, I had to try to guess up front what I should expose in what object. It was the bad old days all over again, writing adhoc code on the server to meet the needs of the client… switching back to GraphQL - and postgraphile - was a relief.

As someone who has used GeaphQL extensively, I really don’t understand most of the complaints, which seem like they’d be common to any complex API surface. Sure you can write a query that triggers a server bug, but that happens with REST too. Yes, your server needs to be hardened against these queries… so what?

And security is hard, granular security doubly so. If you need to do field level authorisation then the problem is that you need a policy engine, not a different query technology.

Re: After 6 years, I'm over GraphQL

#136

Post by vitiral »

I've read the article and a few of the responses but have never used GraphQL. However I have a question

Would it be fair to say that GraphQL is extremely useful for internal-only clients? For example an inhouse data store, query service, test status monitor, etc?

So many issues disappear when you aren't concerned about bad-actors and you have _some_ control over both client and server.

Re: After 6 years, I'm over GraphQL

#137

Post by romanhotsiy »

travellingprog wrote: post #128
probabletrain wrote: post #85

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits: - If data already exists in cache, a query will return that data instead of making a network request. - Everything that has a data dependency on something in the cache will automatically update when the data is updated,…

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

We use https://tanstack.com/query/v3 + openapi-based auto-generated SDK.

I would say the DX is pretty much comparable to using Apollo Client.

Re: After 6 years, I'm over GraphQL

#138

Post by dventimi »

CuriouslyC wrote: post #65
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…

GraphQL by itself has a lot of issues, but Hasura is IMO a power tool. It gives you CRUD with a security model and a lot of bells and whistles out of the box, and paired with Apollo client on the front end it's pretty quick to set up and use. I still use random REST endpoints, and I'm not interested in federation, but as a quick way to get an app going it's great.

Same, with a shout out to PostGraphile as well. As an aside, I'm sorry but I roll my eyes every time I encounter data loaders and the N+1 problem it's meant to address but which really is a consequence of insistence on following the resolver execution model. GraphQL is a query language. Just compile it to SQL (or Cypher, or SPARQL, or whatever)...when that's possible.

Re: After 6 years, I'm over GraphQL

#139

Post by doctor_eval »

SantiagoElf wrote: post #36

Never bothered to learn GraphQL - anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects. Stick to tried and true - monolith, asp.net, angular or blazor front-end, relational database.

> anything being pushed by big tech companies usually in 80% of the cases works for them, but its an overkill for smaller scale projects.

> asp.net, angular or blazor front-end

Since when are these not technologies pushed by big tech companies?

A company I worked with got badly burned by AngularJS.

Re: After 6 years, I'm over GraphQL

#140

Post by mattbrewsbytes »

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

There are so many developers out there that can't stand plugging in proven solutions to problems and just dealing with the trade-offs or minor inconveniences. Nothing is going to be perfect and most likely a lot of the software we write will cease to be running in a decade.

Post reply on HN