Comment by dventimi | Hacker News Reader

Comment by dventimi | Hacker News Reader

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.

I don’t want to overly generalize, but N+1 problems are very real and frequently occur in code written by more junior developers. Their impact and occurrence rate are dependent on the nature of the application though.

I also think there’s an avoidance to simply “translate” a GQL query into an SQL query. Not that it can’t be done, but it allows a lot less flexibility in the backend as far as code patterns that can be adopted. Basically it minimizes the use of ORM models, which may be a pro for some and a con for others.

I haven’t worked with GraphQL in over 4 years since I left my last job. I actively made a choice not to use it at my current job and steered the ship towards REST endpoints, mostly because it would be easier to build authorization middleware. Also like the author of the article discovered, code littered with dataloaders is a pain to maintain.

I grant that the N+1 problem is real, but I reject that it's always a serious problem. That's what I mean when I say this it's overblown.

I'm not persuaded there's an avoidance of translating GraphQL. Rather, I think it's largely because of a lack of awareness of that as an option. Most or all of the material written on the subject exclusively presents execution as matter of nested resolvers and that's how pretty much all the libraries work, so I think it's natural to assume that's the only way to do it.

I will say that translating to SQL does remove a convenient arena in which to write business logic in a general purpose programming language, which generates resistance to the idea of translation once it's encountered. But, as the author says, that mixes business logic with data marshalling code anyway.

N+1 problems were the primary bottleneck in a Websphere backendi worked on for years.

Transactions were being aggregated with thousands to 10s of thousands of SQL statements like this.

    SELECT * from customer
    where id = <single id>

The developers had no idea the ORM was doing this under the hood.

It's trivially easy to say that if every SQL statement took 1ms to execute, that thousands of round trips can really start to tank whatever process it might be blocking.

> It's trivially easy to say that if every SQL statement took 1ms to execute

Good thing I don't say that! What I do say is that the number of SQL calls will tend to scale with the volume of data retrieved. Limit the volume of data the user even is allowed to request and you'll naturally limit the extent of the N+1 problem.

Reply on news.ycombinator.com