[gmassman]

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.

[dventimi]

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.