Live data from Hacker News

After 6 years, I'm over GraphQL

bessey.dev

561–570 of 721 posts

Re: After 6 years, I'm over GraphQL

#561

Earlier quoted context omitted.

Are you really surprised though? Like you alluded, people use Kubernetes and Bazel just because it has the big ol' G stamp on it. GraphQL is no different (Well... slightly different. It's the FB stamp, not the G stamp)

I'm surprised it took so long. I worked with k8s and realised pretty quickly it was pointless for my org.

Yeah that's what I'm saying, it shouldn't be surprising, these delusions last entire careers. Look at all the people who base their career on Java

Re: After 6 years, I'm over GraphQL

#562

Earlier quoted context omitted.

No idea why you bundle Mongo in there. I use Mongo in multiple production apps and I've never, ever looked back. Wouldn't even consider RDBMS's at all after my experience with Mongo unless I absolutely had to.

What kind of "production apps"? A todo list saas? I swear, the older I am, the more convinced I am that people who don't use a RDBMS just don't work on complex systems. Period.

Weird. My experience has been it is the most complex and biggest applications where RDBMS breaks down and you start looking for more scalable options.

Re: After 6 years, I'm over GraphQL

#563

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

To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file. It makes UI changes much much easier to deal with.

I'm a huge fan of this. Apollo doesn't have it baked in as a pattern like Relay does afaik, but I do something similar manually in Apollo, inspired by Relay.

Deleting code automatically removes its data dependencies from the root query, it's ideal.

Re: After 6 years, I'm over GraphQL

#564

I bought into the hype and I feel bad for the company where I implemented it. One true endpoint to rule them all and cause endless headaches in the process. With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want…

One of the things that really burned me out over the years is how many times I would say something to the effect of "Maybe using GraphQL is over complicating the process and we should just use the old tried and true methods" and I would get drowned out by everyone chasing the latest thing or derided for not wanting to try something new.

"Maybe implementing CORBA for message passing is over complicating it." "Maybe using OOP and facade classes is over complicating it." "Maybe using XML to store all the config information is over complicating it." "Maybe using this ORM with a strange file based caching mechanism is over complicating it."

And always get drowned out by everyone going with the trend.

Re: After 6 years, I'm over GraphQL

#565
Former Facebooker here. I have some thoughts. IME I find that many people don't have the problems GraphQL is intended to solve. No shade to the author but, as one example, i don't see the word "fragment" mentioned anywhere in this post and fragments are a real issue with GraphQL.

Let me explain the problem GraphQL actually solves. FB, as we know, is an incredibly large mobile app, possibly one of the largest in terms of actual code. Here are some realities about mobile apps:

1. Once released into the wild, that app version is out there forever. At app installs in the billions this is a serious problem. So you need something that handles versioning of your API. You need something to force you think about versioning and support old versions as long as possible. Again, I don't see the word "version" anywhere in this post. Versioning doesn't seem to be a problem the author has;

2. There are a lot of common objects in the FB app. Posts, comments, etc. When these objects become sufficiently complex, you don't want individual teams pulling out random fields. This is one thing fragments are for. It allows a specialized team define the object model and allow other teams to pull out a subset of that data.

3. FB uses an in-memory graph database for almost all things so issues like N+1 queries (which are real issues if you're talking to a relational DB) don't really come up. The in-memory database has a layer over it that does things like enforce permissions and privacy policies on reads and writes. GraphQL auth is really a superset of this. So if you're querying an endpoint for a user and their blocked users (one example from the post), you probably won't have auth in your endpoint because that'll be enforced by the data access layer that already exists and be written and maintained by a team responsible for that data.

Some comments here have complained that GraphQL is a technology for an organizational problem. I would counter that by saying all technology ultimately is tied to organization. They affect each other.

The above was all done to avoid things like privacy leaks, which at FB's scale is a real problem. Speaking from experience, a significant amount of computing power and software engineering time is tied to avoid these problems by the teams responsible as well as other teams to try and detect an unintentional leak.

How I see a bunch of people use GraphQL (not necessarily the author of this blog post) is as a 1:1 map to a relational model beneath it. That doesn't make a whole lot of sense. GraphQL probably isn't for you.

Re: After 6 years, I'm over GraphQL

#566

Earlier quoted context omitted.

i agree with this. Writing queries is the most annoying part of graphql

I can’t imagine how annoying it would be if we had to write queries in JSON! writing queries is stupid easy if you use a tool like GraphIQL especially with the explorer.

Even better, all of this stuff is integrated into language servers with typechecking based on your gql schema, auto completion, and all the minting checks we’ve come to expect. Is a field nullable but you’re only handling to non-nullable case? The editor catches it.

I think this is a classic case of anecdotes not adding up to data.

Re: After 6 years, I'm over GraphQL

#567

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

To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file. It makes UI changes much much easier to deal with.

I mean technically in relay you need a parent component to make the query for the child components, and pass a reference to those children. There's still a parent/child relationship that needs to be maintained.

Re: After 6 years, I'm over GraphQL

#568

Earlier quoted context omitted.

Those two are kinda orthogonal, and while there was some overlap for adoption, it was fairly common to serve XML over REST early on (because more languages and frameworks had proven-quality XML parsers out of the box, so it was easier for the clients to handle). JSON won in the end mostly because it was easier to handle in JS specifically, which is what mattered for the frontend. Then other languages caught up with t…

To claim that pretty much every .NET project adding Newtonsoft.JSON as a first step was somehow a problem is just strange. No adequate team would claim this to be a problem.

It was enough of a problem that Microsoft eventually saw it fit to come up with the official replacement.

Re: After 6 years, I'm over GraphQL

#569

Earlier quoted context omitted.

swr can handle the first issue you mentioned just fine.

I'm not sure I follow. Are you saying swr allows for fragments and deduplication? If you don't have fragments (in particular, if you have a single call to an swr hook at the root), then you have implicit deduplication. But then you run into the issue of it being unclear whether you can remove a given field when a subcomponent stops using it — you have to check whether any other subcomponent happens to use that. And i…

I think you updated your comment.

Re: After 6 years, I'm over GraphQL

#570
post #435

Earlier quoted context omitted.

Someone like you made me quit my first job as developer. He implemented a Clojure + GraphQL nightmare.

Well that wasn't me, I implemented an Akka + GraphQL nightmare instead :) Joking aside, I'm sorry that happened to you and I'm sorry for the people that took over the system I helped to write.

Been there, done that.

Did Akka; thank goodness that didn't make it to production.

GraphQL: Helped in many ways. Hurt in so many too. In production.

Everything in Actors: State was everywhere. So much pain. In production.

I just use Postgres + RPCs for everything now.

Post reply on HN