3 ms·

> If the frontend devs come up with the GraphQL schema definition, they could also come up with a single REST request definition with very specific DTOs needed

> If the frontend devs come up with the GraphQL schema definition, they could also come up with a single REST request definition with very specific DTOs needed for that particular view/workflow The GraphQL schema is a unified, standardized language that describes these objects, types and relations. How many different flavours of REST exist out there? Every company interprets REST slightly differently, uses different conventions etc. Imagine every company in the world that uses REST in any capacity used the same documentation tools (eg. swagger), same conventions to describe relations, where all the tools could automatically generate code and types from the API definitions, with zero effort from the development team. What a wonderful world.

littlecranky67 8y ago
While I agree about people being very vocal about the "right" REST this will not be an issue in this scenario. If you design UI-first and want that little "single HTTP request" that contains all data, you will very likely just define a single DTO entity which will be JSON data - very widely used and understood. There is not much ambiguity in REST here to do it "wrong". If we talk about write operations/commands, you have the same issues with GraphQL mutations as with REST, there is more than one way to do it, semantics might vary, people will create special fields on the DTO payloads to carry error codes, transactional ids etc. No standards here on both sides of the curtain. I've seen people doing multiple HTTP POSTs do something that should be transactional and a single HTTP POST with rollback on failure; and I am sure there are GraphQL APIs out there that do the same operation performing multiple GraphQL mutations that should be a single, safe transaction etc. Plus, while REST semantics is debatable and many flavours exist, some common ground like error codes and defined cache semantics exist that integrate well with existing solutions (caching CDN, Loadbalancer etc.) while GraphQL is very lose on this end.

littlecranky67 8y ago

While I agree about people being very vocal about the "right" REST this will not be an issue in this scenario. If you design UI-first and want that little "single HTTP request" that contains all data, you will very likely just define a single DTO entity which will be JSON data - very widely used and understood. There is not much ambiguity in REST here to do it "wrong". If we talk about write operations/commands, you have the same issues with GraphQL mutations as with REST, there is more than one way to do it, semantics might vary, people will create special fields on the DTO payloads to carry error codes, transactional ids etc. No standards here on both sides of the curtain. I've seen people doing multiple HTTP POSTs do something that should be transactional and a single HTTP POST with rollback on failure; and I am sure there are GraphQL APIs out there that do the same operation performing multiple GraphQL mutations that should be a single, safe transaction etc. Plus, while REST semantics is debatable and many flavours exist, some common ground like error codes and defined cache semantics exist that integrate well with existing solutions (caching CDN, Loadbalancer etc.) while GraphQL is very lose on this end.