5 ms·

How is that different than with REST? It sounds like the advantage you're citing is a separation of code into client and server, with a well-specified API betw

by toomim 8y ago

How is that different than with REST? It sounds like the advantage you're citing is a separation of code into client and server, with a well-specified API between the two. You can write a well-specified API with either REST or GraphQL. Is there something about GraphQL in particular that is helping here?

tohjustin 8y ago
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.
jahewson 8y ago
GraphQL allows the front end developers to effectively write their own ad-hoc queries (on top of whatever primitives the backend devs provide them), whereas in REST each query would have to be a custom endpoint on the backend. Or possibly many custom endpoints depending on how REST-y you want to be.
- littlecranky67 8y ago
  The big issue with GraphQL that I see is maintaining the API contracts over time. The GraphQL queries are defined and stored somewhere in your JS frontend code, iOS or Android App Code. If the backend team refactors the API because some requirements changed, there is no way the backend team can easily verify that the GraphQL queries still run successfully. Whereas when using a REST API approach, all the Endpoints are within the backend domain. If some properties of your DAO change or get dropped, the DTO<->DAO mapping in the backend will likely break during compile time and the backend team would know that their change affects the contracts implemented by the clients. With GraphQL, such changes would go unnoticed until the frontend dev teams test against new API versions. While you could use stored GraphQL queries to overcome this, I don't see the benefit here. You backend devs would need to be able to "speak" (learn) GraphQL (maintain the unit tests etc.), whereas in a REST world your frontend devs would need to learn REST.
  - sshumaker 8y ago
    First off, schemas are stored so they are accessible to the GQL server (not with FE code). Maintaining API contracts is much easier with GraphQL than with REST (even if you layer on top a contract system like Swagger). The major advantage to GraphQL (which has a powerful schema system) is that you can explicitly know which fields are being accessed. The query itself represents what the client understands (capabilities). This makes it much easier to maintain backwards compatibility. You can even monitor traffic per field to deprecate features. Re: BE code breaks, that’s what integration tests are for.
    - littlecranky67 8y ago
      How is ANY of this different that REST? REST is very explicit about the available fields and data as it is represented by the API endpoints and their DTO formats. And with GraphQL you can tell (from the server side) which data a client requests based on the query, but there is no guarantee that the client uses all this data to display in the UI view, same as you can't know whether the client uses all the data with REST. If you start UI-first, your REST Endpoints also match exactly the UI requirements of your App, and your DTOs will contain exactly what is needed to render a specific UI. No advantage in GraphQL world here. > Re: BE code breaks, that’s what integration tests are for. Agreed, but for this to work you have to have the GraphQL queries that reside in your frontend code in the backend test suite. While it would be good practice to run your iOS/Android/Web App against builds of the backend, you hardly find this level of integration tests in the wild. With REST you test the queries by testing the API endpoints which can be simple HTTP operations with object/result assertions.
deleted 8y ago
[deleted]
hn_throwaway_99 8y ago
I think the difference is somewhat slight but actually really critical. With REST, a common pattern is that you have our RESTful APIs return "business objects", but then down in the UI layer of the app you have a bunch of logic to turn these into "presentation objects". There are a couple problems with this: 1. If you have to support multiple front ends, like Android and iOS, you have to dupe all this logic. 2. If you have native apps, it makes it MUCH more difficult to change your backend APIs without breaking things. 3. Related to #2 above, GraphQL provides a much better paradigm for maintaining backwards compatibility than REST. What other folks have said is somewhat true, with GraphQL a lot of what you do is "push up" code from the client up into the server. However, especially with native apps where you can't necessarily control when users upgrade, it is a huge benefit to be able to update that code serverside instead of clientside.
- littlecranky67 8y ago
  Except that the backwards compatible point is nonsense and actually a PRO REST argument. If your database schema changes (or the orchestrated microservices), i.e. a field in a table gets dropped (lets say new security policies make this field not readable to everyone) you have NO way of making that change without breaking your GraphQL queries. Because you cannot update that queries that are stored on your users Apps, you will end up having more and more hacks in your GraphQL Server to account for all possible query combinations that are out in the wild. And because you have to account for those hacks, you will need to maintain a list of all old and deprecated queries that exist(ed) in your frontend code and make it available to the backend devs, that maintain the hacks in the GraphQL server adapter. With REST, you would have to do the same hacks of course to maintain backwards compatibility - but as the REST Endpoint (and the queries they represent) reside in the backend and are not updated or removed, it is way easier to keep track of the hacks to maintain compatibility.
  - hn_throwaway_99 8y ago
    This is absolutely not correct, but it is a common misunderstanding I've seen with how people use GraphQL. I've posted this before, but I despise how GraphQL has "QL" in the name, so folks think it is similar to SQL in that you should expose your database tables as-is with GraphQL queries. You should absolutely not do this. You should design your GraphQL contracts to closely match the views displayed in your UIs - it even says this in the GraphQL spec: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." If your GraphQL types closely hew to the design of your views, it shouldn't matter how you store them under the covers, and clients should have no need to know any details about the underlying storage schema.

by toomim 8y ago

tohjustin 8y ago

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.

jahewson 8y ago

GraphQL allows the front end developers to effectively write their own ad-hoc queries (on top of whatever primitives the backend devs provide them), whereas in REST each query would have to be a custom endpoint on the backend. Or possibly many custom endpoints depending on how REST-y you want to be.

littlecranky67 8y ago
The big issue with GraphQL that I see is maintaining the API contracts over time. The GraphQL queries are defined and stored somewhere in your JS frontend code, iOS or Android App Code. If the backend team refactors the API because some requirements changed, there is no way the backend team can easily verify that the GraphQL queries still run successfully. Whereas when using a REST API approach, all the Endpoints are within the backend domain. If some properties of your DAO change or get dropped, the DTO<->DAO mapping in the backend will likely break during compile time and the backend team would know that their change affects the contracts implemented by the clients. With GraphQL, such changes would go unnoticed until the frontend dev teams test against new API versions. While you could use stored GraphQL queries to overcome this, I don't see the benefit here. You backend devs would need to be able to "speak" (learn) GraphQL (maintain the unit tests etc.), whereas in a REST world your frontend devs would need to learn REST.
- sshumaker 8y ago
  First off, schemas are stored so they are accessible to the GQL server (not with FE code). Maintaining API contracts is much easier with GraphQL than with REST (even if you layer on top a contract system like Swagger). The major advantage to GraphQL (which has a powerful schema system) is that you can explicitly know which fields are being accessed. The query itself represents what the client understands (capabilities). This makes it much easier to maintain backwards compatibility. You can even monitor traffic per field to deprecate features. Re: BE code breaks, that’s what integration tests are for.
  - littlecranky67 8y ago
    How is ANY of this different that REST? REST is very explicit about the available fields and data as it is represented by the API endpoints and their DTO formats. And with GraphQL you can tell (from the server side) which data a client requests based on the query, but there is no guarantee that the client uses all this data to display in the UI view, same as you can't know whether the client uses all the data with REST. If you start UI-first, your REST Endpoints also match exactly the UI requirements of your App, and your DTOs will contain exactly what is needed to render a specific UI. No advantage in GraphQL world here. > Re: BE code breaks, that’s what integration tests are for. Agreed, but for this to work you have to have the GraphQL queries that reside in your frontend code in the backend test suite. While it would be good practice to run your iOS/Android/Web App against builds of the backend, you hardly find this level of integration tests in the wild. With REST you test the queries by testing the API endpoints which can be simple HTTP operations with object/result assertions.

deleted 8y ago

[deleted]

hn_throwaway_99 8y ago

I think the difference is somewhat slight but actually really critical. With REST, a common pattern is that you have our RESTful APIs return "business objects", but then down in the UI layer of the app you have a bunch of logic to turn these into "presentation objects". There are a couple problems with this: 1. If you have to support multiple front ends, like Android and iOS, you have to dupe all this logic. 2. If you have native apps, it makes it MUCH more difficult to change your backend APIs without breaking things. 3. Related to #2 above, GraphQL provides a much better paradigm for maintaining backwards compatibility than REST. What other folks have said is somewhat true, with GraphQL a lot of what you do is "push up" code from the client up into the server. However, especially with native apps where you can't necessarily control when users upgrade, it is a huge benefit to be able to update that code serverside instead of clientside.

littlecranky67 8y ago
Except that the backwards compatible point is nonsense and actually a PRO REST argument. If your database schema changes (or the orchestrated microservices), i.e. a field in a table gets dropped (lets say new security policies make this field not readable to everyone) you have NO way of making that change without breaking your GraphQL queries. Because you cannot update that queries that are stored on your users Apps, you will end up having more and more hacks in your GraphQL Server to account for all possible query combinations that are out in the wild. And because you have to account for those hacks, you will need to maintain a list of all old and deprecated queries that exist(ed) in your frontend code and make it available to the backend devs, that maintain the hacks in the GraphQL server adapter. With REST, you would have to do the same hacks of course to maintain backwards compatibility - but as the REST Endpoint (and the queries they represent) reside in the backend and are not updated or removed, it is way easier to keep track of the hacks to maintain compatibility.
- hn_throwaway_99 8y ago
  This is absolutely not correct, but it is a common misunderstanding I've seen with how people use GraphQL. I've posted this before, but I despise how GraphQL has "QL" in the name, so folks think it is similar to SQL in that you should expose your database tables as-is with GraphQL queries. You should absolutely not do this. You should design your GraphQL contracts to closely match the views displayed in your UIs - it even says this in the GraphQL spec: "Product‐centric: GraphQL is unapologetically driven by the requirements of views and the front‐end engineers that write them. GraphQL starts with their way of thinking and requirements and builds the language and runtime necessary to enable that." If your GraphQL types closely hew to the design of your views, it shouldn't matter how you store them under the covers, and clients should have no need to know any details about the underlying storage schema.