First off, thanks for the post. I learned a lot and it was very informative. Your definitions, analysis, and proposal are interesting.
I work for a company that is trying to decide what to do for public APIs that we'll be building in the next several months. The main options we've considered so far are REST and GraphQL, with our company background being in RESTful APIs that Roy would probably have some beef with 😄.
In the past few weeks I've been diving into GraphQL trying to understand it better so we can make an informed decision. Your section about GraphQL had a paragraph in it that is something that I used to believe about GraphQL, but now believe to not be true. Which is what caused me to create this issue -- I'd like to understand better what you meant by it.
Here's the paragraph:
the server engineer must take full responsibility for supporting all kind of queries the client might need and at the same time these queries need to be efficient and scalable. When we can know in advance what are the limits of a query, we are able to optimize for it, however, with GraphQL, a client can send any query using any of the all the possible resources and structure them in a way that for the server is random. In such cases, it's impractical to optimize beforehand and solving scaling issue becomes a real challenge that possibly only companies with huge amount of resources can really afford.
I used to believe this, but now consider it a common misconception about GraphQL. What changed my perspective was that I started building a GraphQL server and realized that queries to a graphql service are only valid if they meet the requirements of the GraphQL schema.
Example 1:
I used to believe that in any query you could filter by any field. But now have learned that the following, although valid GraphQL syntax, is not actually supported by a server unless you explicitly say it should be in the schema:
# Valid GraphQL syntax, but if the server doesn't support it, the introspection tools will warn
# and the request won't even pass the GraphQL schema check
{
allUsers(id: "1") {
id
name
}
}
Example 2:
I used to believe that GraphQL required the server to allow for nesting collections of data arbitrarily deep. Here's an example of the type of query that is valid GraphQL syntax that used to get me scared:
# Valid GraphQL syntax, but if the server doesn't support it, the introspection tools will warn
# and the request won't even pass the GraphQL schema check.
{
allTeachers {
id
name
courses {
id
name
sections {
id
timeSlot
students {
id
name
courses {
id
name
teacher {
id
name
}
}
}
}
}
}
}
But now I've learned that although the query is valid syntax, it is not supported by a GraphQL server unless the server explicitly says that it supports it.
Could you help me understand what exact use cases you were talking about in that paragraph? I worry I am still missing something about GraphQL's query language or schema definition language.
First off, thanks for the post. I learned a lot and it was very informative. Your definitions, analysis, and proposal are interesting.
I work for a company that is trying to decide what to do for public APIs that we'll be building in the next several months. The main options we've considered so far are REST and GraphQL, with our company background being in RESTful APIs that Roy would probably have some beef with 😄.
In the past few weeks I've been diving into GraphQL trying to understand it better so we can make an informed decision. Your section about GraphQL had a paragraph in it that is something that I used to believe about GraphQL, but now believe to not be true. Which is what caused me to create this issue -- I'd like to understand better what you meant by it.
Here's the paragraph:
I used to believe this, but now consider it a common misconception about GraphQL. What changed my perspective was that I started building a GraphQL server and realized that queries to a graphql service are only valid if they meet the requirements of the GraphQL schema.
Example 1: I used to believe that in any query you could filter by any field. But now have learned that the following, although valid GraphQL syntax, is not actually supported by a server unless you explicitly say it should be in the schema:
Example 2: I used to believe that GraphQL required the server to allow for nesting collections of data arbitrarily deep. Here's an example of the type of query that is valid GraphQL syntax that used to get me scared:
But now I've learned that although the query is valid syntax, it is not supported by a GraphQL server unless the server explicitly says that it supports it.
Could you help me understand what exact use cases you were talking about in that paragraph? I worry I am still missing something about GraphQL's query language or schema definition language.