> You could also define a single REST endpoint that contains all the information to load the page and mimic the GraphQL behavior. But this would just shift the burden of dealing with complexity from the client to the backend. And while that may be viable for simple applications, it would not be in more complex ones.
I don't get it, how is this significantly more complex than what the author suggests? How is this shifting complexity to the backend with REST and not with GraphQL if all you're changing is the transport layer?
GraphQL more clearly makes sense if you're designing some public API used by third-party devs, like Facebook did. It can also make sense for large private APIs. But I wouldn't jump to it unless the "regular" way is presenting problems.
Like one time, I was working on a social kind of app. I thought, lemme give a separate endpoint to get each kind of object (user, post, etc) so the client can cache stuff. Frontend devs instead wanted everything needed to render each page in one call, which is understandable. I gave them that, but often they'd later need something I wasn't sending back yet, which slowed down development. So I started sending extra fields back just in case, e.g. sending a full public user object for some page that only needs the name and avatar. In short, it got wasteful, but not the end of the world. GraphQL would've made it cleaner, but it also had an upfront cost.
I don't get it, how is this significantly more complex than what the author suggests? How is this shifting complexity to the backend with REST and not with GraphQL if all you're changing is the transport layer?