GraphQL does solve its problems. It's often very fun to use, and can save a lot of efforts if adopted correctly. However, no matter how good or practical it is

GraphQL does solve its problems. It's often very fun to use, and can save a lot of efforts if adopted correctly. However, no matter how good or practical it is, you should mind that it's not "technology" after all. It's just an industrial solution that adopts a (relatively) new development pattern. It doesn't solve any complexities inherent to the web technologies, but merely re-adjusts the developers' responsibilities (= shifting burdens to consumers). This is a human problem (though still is an engineering problem), and is NOT a technical problem. Thus one must approach GraphQL accordingly: does our "organization" need to re-adjust developers' responsibilities? Can we benefit from changing our development pattern/workflow? This is not an easy question to answer, but there can be some noticeably easy cases. Say, if your FE is relatively huge/fast so that BE people simply can't catch up with it, GraphQL will be a fantastic solution. If there are too many brain-dead CRUD APIs that keep sucking up BE engineering resources (= low ROI) and causing stupid down times and development delays, GraphQL can save you. So, when you review GraphQL, it should be reviewed in the organizational level. You should find the issues in the workflow, not in the current implementation of your service. You should struggle to improve the speed of the development and to save the engineering cost. In the end, you should NOT think this is a "better technology".