3 ms·

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

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.