3 ms·

At Facebook, GraphQL is used in a such a way that all queries are predeclared -- developers write a collection of queries that represent their client's interfac

At Facebook, GraphQL is used in a such a way that all queries are predeclared -- developers write a collection of queries that represent their client's interface to the backend, and only these queries are used in the live app. This has two positive effects: * It's fairly easy to tell "how the app is using the database" -- queries are not dynamically generated or hidden in code. * The query performance is predictable and controllable in the same way as a stored procedure approach to database access -- but without actually requiring a DBA to load/unload procedure definitions. One might argue that these benefits could be obtained without codifying a new query language...but when you start to think about nested objects you start to warm up to the idea.

KirinDave 9y ago
This makes a LOT more sense. The compiler part is what keeps hanging me up.
michaelchisari 9y ago
> when you start to think about nested objects you start to warm up to the idea. You do, but any time you try to solve a problem, and your solution ends up being a new language, I think it's worth asking yourself, "Am I overcomplicating this? Can I do this in a simpler way?" And I think you can. I've been toying with an approach I like to call http-etc, which is a simple idea that lets you flag the http (rest) api to say, "Give me this data, but also give me the graph associated with this data." For instance, if I want an article, I would do: /api/0.1/article/z098d0s8dga That would give me information about the article with the slug or internal id of z098d0s8dga. But if I want an article, plus the comments associated with it, and information about the users that posted those comments, I can do: /api/0.1/article/z098d0s8dga+ You have two routes that are very similar but work in completely different ways. One gets specific information, the other returns the graph from a specific starting point. And this is handled completely with your server-side api design. You have your singular route to one function, and you have your "etc" route to another function. Synchronizing the shape of the data requested/returned between server and client is still handled manually, but it seems to me this pattern solves 90% of GraphQL use cases with 1% of the complexity of GraphQL. It isn't tied to any specific language or codebase on the server-side. It doesn't require a big client-side library be added to your project. It's just a simple pattern.
- alvis 9y ago
  I cannot agree more on that having a simpler and clearer pattern is perhaps what we need. Solving 90% of GraphQL use cases with 1% of the complexity is a killing point to me.
- solidsnack9000 9y ago
  With this approach, how do you filter stuff out below the sub graph?

KirinDave 9y ago

This makes a LOT more sense. The compiler part is what keeps hanging me up.

michaelchisari 9y ago

> when you start to think about nested objects you start to warm up to the idea. You do, but any time you try to solve a problem, and your solution ends up being a new language, I think it's worth asking yourself, "Am I overcomplicating this? Can I do this in a simpler way?" And I think you can. I've been toying with an approach I like to call http-etc, which is a simple idea that lets you flag the http (rest) api to say, "Give me this data, but also give me the graph associated with this data." For instance, if I want an article, I would do: /api/0.1/article/z098d0s8dga That would give me information about the article with the slug or internal id of z098d0s8dga. But if I want an article, plus the comments associated with it, and information about the users that posted those comments, I can do: /api/0.1/article/z098d0s8dga+ You have two routes that are very similar but work in completely different ways. One gets specific information, the other returns the graph from a specific starting point. And this is handled completely with your server-side api design. You have your singular route to one function, and you have your "etc" route to another function. Synchronizing the shape of the data requested/returned between server and client is still handled manually, but it seems to me this pattern solves 90% of GraphQL use cases with 1% of the complexity of GraphQL. It isn't tied to any specific language or codebase on the server-side. It doesn't require a big client-side library be added to your project. It's just a simple pattern.

alvis 9y ago
I cannot agree more on that having a simpler and clearer pattern is perhaps what we need. Solving 90% of GraphQL use cases with 1% of the complexity is a killing point to me.
solidsnack9000 9y ago
With this approach, how do you filter stuff out below the sub graph?