3 ms·

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,

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.

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.