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