3 ms·

I guess it's makes the front-end a whole lot easier to implement. To fetch all the data that the app needs to render on a single view, the code would only need

I guess it's makes the front-end a whole lot easier to implement. To fetch all the data that the app needs to render on a single view, the code would only need to make a single API call to a graphql endpoint and you only have to deal with a single, neatly formatted response. As opposed to the traditional way of making multiple calls to different REST endpoints, you had to write quite a bit of code to transform & merge the data from each response before using them to render your views.

littlecranky67 8y ago
> To fetch all the data that the app needs to render on a single view, the code would only need to make a single API call to a graphql endpoint and you only have to deal with a single, neatly formatted response. 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. You would have the same single, neatly formatted response (caching included). There is no difference what technology you use here, as long as your API is designed UI-first and your API design (or the REST facade for microservice orechstration) is developed according to the UI. If you go API-first, you will end up doing lot of REST calls to get the data you need for your view, but you would encounter the same problems if you were to model your GraphQL queries API-first, before you design the UI workflow.
- wereHamster 8y ago
  > 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.
boubiyeah 8y ago
If you're using graphQL just for that... You can expose a POST endpoint that can follow relation (GET) links recursively, starting from a base resource. It's a bit of work but still far less than implementing a good schema, resolvers, etc. And much less technological coupling to a particular solution (apollo, etc).
- wereHamster 8y ago
  > And much less technological coupling to a particular solution (apollo, etc). You are confusing a specification (GraphQL) with an implementation (Apollo). You don't need apollo to access a graphql server. A plain old HTTP POST is all that you need. From a web browser, use the builtin `fetch()` function and be done. No coupling whatsoever.
  - boubiyeah 8y ago
    I'm not confusing anything, but regardless of which solution ones chooses, the implementation is nothing but trivial and people usually turn to fully ready implementations like apollo.

littlecranky67 8y ago

> To fetch all the data that the app needs to render on a single view, the code would only need to make a single API call to a graphql endpoint and you only have to deal with a single, neatly formatted response. 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. You would have the same single, neatly formatted response (caching included). There is no difference what technology you use here, as long as your API is designed UI-first and your API design (or the REST facade for microservice orechstration) is developed according to the UI. If you go API-first, you will end up doing lot of REST calls to get the data you need for your view, but you would encounter the same problems if you were to model your GraphQL queries API-first, before you design the UI workflow.

wereHamster 8y ago
> 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.

boubiyeah 8y ago

If you're using graphQL just for that... You can expose a POST endpoint that can follow relation (GET) links recursively, starting from a base resource. It's a bit of work but still far less than implementing a good schema, resolvers, etc. And much less technological coupling to a particular solution (apollo, etc).

wereHamster 8y ago
> And much less technological coupling to a particular solution (apollo, etc). You are confusing a specification (GraphQL) with an implementation (Apollo). You don't need apollo to access a graphql server. A plain old HTTP POST is all that you need. From a web browser, use the builtin `fetch()` function and be done. No coupling whatsoever.
- boubiyeah 8y ago
  I'm not confusing anything, but regardless of which solution ones chooses, the implementation is nothing but trivial and people usually turn to fully ready implementations like apollo.