[tomnipotent]

I always thought it was about developer velocity, in this particular case front-end. With a traditional REST API the front-end team needed to coordinate with the back-end team on specific UX features to determine what needed to be done, which was further exasperated when API's needed to be specialized for iPhone vs. Android vs. Web UI.

GraphQL was supposed to help front-end and back-end meet in the middle by letting front-end write specific queries to satisfy specific UX while back-end could still constrain and optimize performance. Front-end could do their work without having to coordinate with back-end, and back-end could focus on more important things than adding fields to some JSON output.

I think it's important to keep this context in mind to appreciate what problem GraphQL is solving.

[nevertoolate]

I think I understand this, possibly nice for huge client x feature matrix. I don’t have XP in the setup where there is a big separate backend team. In my head there is an alternative implementation: have a separate routing layer (coauthored by backend and frontend). Backend responsibility ends with the service layer. There has to be some domain contract implemented somewhere, question is it is simpler to cut down from a tree or build something on top of components.

[chao-]

This is my read of the history as well.

This is also the motivation that would lead me to advocate for adopting GraphQL for a product. Moreso than a technical decision, it is an organizational decision regarding resource trade-offs, and where the highest iteration or code churn is expected to be located.