The following is the first few sections of a chapter from GraphQL and Android, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Authentication and the Viewer Pattern

Usually Web services are authenticated, so that only authorized users can access them, whether through a Web app, an Android app, or something else. GraphQL-based Web services are no different in this regard. So far, we have ignored this point, by hitting a public read-only server (the book’s demo server) or a local test server (which hopefully nobody but you can access). To be more realistic, we need to consider actual authentication approaches.

GraphQL’s schema-based approach, though, adds an interesting implementation wrinkle: different users can see different schemas, based on what they are authorized to do on that server. This would be the equivalent of some REST URLs being eligible for some users but failing with an HTTP 401 error for other users.

Convention Over Specification

Part of what makes GraphQL powerful is a specification, so that everyone can agree on what it means to request and consume GraphQL.

That specification does not span to transports, such as HTTP/HTTPS. And while the GraphQL documentation talks a bit about GraphQL as a Web service, authentication is not one of the topics that it covers, at least as of July 2017.

However, a few conventions have arisen related to authentication in GraphQL. Sometimes, these conventions are simply “ports” of approaches used elsewhere, such as JSON Web Tokens (JWT) as a means of offering authentication. Sometimes, these conventions are more unique to the GraphQL space, or at least are not directly equivalent to techniques that you might use with REST or other counterparts.

What You Get Stems From Who You Are

The preview of this section is sleeping in.

Exploring GitHub’s Approach

The preview of this section will not appear here for a while, due to a time machine mishap.