The Apollo team's Medium publication on GraphQL, covering the Apollo data stack, Apollo Server, query batching and static queries.
HN commenters point to it as a good source on overall GraphQL architecture, though the given comments mostly discuss GraphQL APIs and access control in general.
> secure and scalable
> over the Internet
What does this really mean? How does this substantially differ from the now-facetious term 'web scale' [1] ?
Modern RDBMS'es offer encrypted communications between client and server [2][3][4], but nothing is stopping a deployer from putting a proxy between the database and the Internet-resident end-user to translate between authentication mechanisms. In fact, this happens in every single API today, where the Basic or OAuth or Cookie-Auth request comes in the HTTP body, and gets made into a database query in a query language the DB understands -- SQL or something else.
GraphQL needs to you bring your own authn/z [5][6][7] much the same way that your run-of-the-mill HTTP API needs to you to bring your own authn/z, so I can't accept 'secure' as an innovation over SQL. "Scalable?" How?
I genuinely think this tech is neat but let's consider what it gives you. GraphQL packages together the query language known as GraphQL, the IDL/typespec language known as GraphQL, the server spec known as GraphQL which a GraphQL-compliant server must implement [8], inside which you have to hook up your actual datastore to the GraphQL server [9][10][11][12]. It's a useful tool to build a client-server system where you're going to make a backend query in the end, but I wonder if its full potential will be realized when there are GraphQL-capable datastores to skip that extra data munging layer you have to implement yourself; but if SQL were passed on…
I'd love to hear how Github is doing ACL here. We came up with a pretty neat solution on my team, which we have not yet open-sourced, for JS. But it was a lot of first-principles design work; there don't seem to be any good examples.
This was pretty much all the documentation we had, and it's more a design analysis of edge-vs-node authorization: https://medium.com/apollo-stack/auth-in-graphql-part-2-c6441bcc4302#.he0radbju
Edit: Our eventual solution looked a lot like
class SomeTypeOfResolver {
@allowIfAny(rule1, rule2, rule3)
someProperty;
@allowIfAll(rule4, rule5)
otherProperty = defineRetrieverFunction();
}
Perhaps http://graphql.org/blog/rest-api-graphql-wrapper/ might be useful. Also the Apollo team has a good blog with many articles on the overall GraphQL architecture https://medium.com/apollo-stack