41–50 of 84 posts
Why invent syntax when you can specify the queries in JSON, too? MQL did it, and it was amazing: http://wiki.freebase.com/images/e/e0/MQLcheatsheet-081208.pd...
Earlier quoted context omitted.
When building out a GraphQL schema, the schema developer chooses which functionality to expose to the client. So rather than having the client do operations or predicates directly, the server declares what functionality is available, and might expose functionality that ordinarily would have used operators or predicates. For example, we might have the following query on Facebook's GraphQL schema: { user(id: 4) { follo…
Any idea when this will work with Relay?
To take the Star Wars example at https://github.com/facebook/graphql and build on it. Let's say after this is deployed we need to expose a Planet's population as well. Now homePlanet goes from being a String to a Planet { name population } object.
This type change would break existing clients - the only real solution I can think of is introducing the planet object as PlanetDetails (essentially PlanetV2) and deprecating planet, but that's just back to versioning.
I feel like there must be a better way to deal with it? Interestingly, the graphql format allows this to be differentiated (as the old API won't request an object), but there appears to be no provision to union two non-objects into a single field?
Version Free sounds amazing - I can see the pros of being able to add/deprecate fields at the same API endpoint, but I find most of the reason we version our API is for field type changes as the data schema naturally evolves. We need to keep track of finer grained data in existing fields that wasn't originally thought of. To take the Star Wars example at https://github.com/facebook/graphql and build on it. Let's say…
It's totally unclear to me that GraphQL solves data migration problems.
Earlier quoted context omitted.
This is how Relay currently works
You can't presently pass other filtering arguments to a relay query. Just IDs. Unless I am missing something, the above query wouldn't work in Relay.
But arbitrary arguments on any other field are totally supported.
Implementing API-specific functions in the query? That looks an awful lot like adhoc RPC endpoints, because the functionality is application-specific.
I just don't get the hype. Poor documentation, no robust reference implementation... nothing novel about the query language itself. Function calls in queries is pretty much just RPC (even if you say "declarative" a lot). And if it's about graph data it's incredibly limited compared to SPARQL.
Every time there's a new post about GraphQL, I become even more concerned that "GraphQL" was the wrong name to use publicly. It seems like most people assume it's just another combination of two buzzwords, Graph and QL, and incorrectly pattern match it. In an attempt to help resolve this issue, I suggest that you think of it as ProductQL or ProductAPI instead. It's not a storage layer. It's not really a query languag…
Version Free sounds amazing - I can see the pros of being able to add/deprecate fields at the same API endpoint, but I find most of the reason we version our API is for field type changes as the data schema naturally evolves. We need to keep track of finer grained data in existing fields that wasn't originally thought of. To take the Star Wars example at https://github.com/facebook/graphql and build on it. Let's say…
Whereas contrasting with REST versioning or traditional versioning, it becomes quite difficult to mix API versions internally (each callsite needs to specify their desired api version before specifying fields) or impossible outright. If the latter, you're then forced to migrate all at once from a given version to another, which requires a ton of coordination across teams and big scary "flip the switch" moments.
This gets worse as you scale up your org, which is why GraphQL has served FB well.