> For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end sp

> For GraphQL, reducing client/datacentre round trips is nice, but can also easily be achieved with RESTful “coordination” services, that serve the front end specifically, and do nothing but stringing together calls to backend services. I mean . . . that's all a GraphQL "server" (or parser/aggregator endpoint) is. > Why force people to learn another complex technology for that? Because most later-stage 'RESTful “coordination” services' like you describe probably already include: 1) a DSL of some kind for expressing what data you like; 2) significant complexity for expressing grouping or deduplication logic; 3) complex requirements for coordinated backend services so that their "raw" data can be rolled up un an efficient and uniform way by the coordinator. That's complex, and new to most people--pretty much everyone who starts work on it, if you built it yourself. GraphQL queries and aggregation layers are similarly complex, but new to fewer people, and better supported. I think there are some big problems with GraphQL as a concept/technology (I am currently pushing back against its adoption in my area), but the above are not the right criticisms.