It's less about what front-end engineers are allowed to do, and more about having an abstraction flexible enough that new front-end features don't need changes

It's less about what front-end engineers are allowed to do, and more about having an abstraction flexible enough that new front-end features don't need changes on the backend unless the data model changes. Backend or full stack engineers can design endpoints however they want, whether it's RESTful JSON or gRPC, and GraphQL acts as a flexible aggregation and presentation layer. If you're finding that your endpoints are filled with unnecessary optional fields, that they're specific to a single screen in the UI, that nearly every new feature involves work that's duplicated across front-end and backend, or that you're suffering a performance hit from the round-trip time between front-end and backend when you query nested objects, then GraphQL can be an option. These are problems that you run into when your product starts to get bigger and more unwieldy, so if your UI has five screens and doesn't reuse the same content then you might not see a lot of gain. Having said that, my former company was under ten engineers, so I don't think you need to be Facebook-scale to benefit. Totally agree that the advantage is architectural. It's not a question of technical merits or of REST being bad. GraphQL is a layer of abstraction to separate data from presentation, and like other abstractions, you shouldn't use it unless you have a reason to.