5 ms·
It doesn't lose it - it just doesn't remain an advantage over the alternative. It's not like if there is a schema with a REST API, the GraphQL alternative beco
by ar_lan 6y ago
It doesn't lose it - it just doesn't remain an advantage over the alternative.
It's not like if there is a schema with a REST API, the GraphQL alternative becomes un-typed.
- cratermoon 6y agoWhat's the difference between "losing it" and "it doesn't remain"? I didn't say GraphQL lost the feature, I said it lost the advantage. I see also the paper says, in bold, "it is unfair to attribute the gains observed with GraphQL only to the IDE", but elsewhere they trumpet the ability of the IDE to interpret and enforce the schema as significant. And again, we can accept that the feature is useful without conceding that GraphQL has the advantage. We could just as well have an IDE that understands OpenAPI specs an accomplish the same thing.
- t-writescode 6y agoYou said "benefit", not advantage.
- cratermoon 6y agoI did not, I was paraphrasing the paper. "By triangulating the results of RQ1 and RQ2, it is clear that the avaliability of a type system — expressed as a schema — is one of the key benefits provided by GraphQL, in terms of reducing the effort to implement queries, when compared to REST." The paper itself was using the word benefit in comparison to REST.
- yxhuvud 6y agoFWIW, the types possible to express in gql is quite a lot weaker than the ones in openapi, where you can for example say not only is a field a string, but also that it matches a certain format.
- lukeramsden 6y agoYou can create custom scalars in GraphQL, which then have shared logic for serialization on the backend and frontend. That knowledge on format does have to be sort of out-of-band but that could probably be added to the standard.