The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, 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

Different GraphQL Web services will use different approaches for authentication. GitHub — whose Web service we will begin exploring in this chapter — uses an API key, known as an authentication token, in an HTTP Authorization header. And in the case of GitHub, if you do not have such a header, you get an HTTP 401 response from any GraphQL request.

However, clearly, it is possible for a GraphQL Web service to accept requests without authentication, as the book’s demo server and your local copy demonstrate.

What is interesting about GraphQL is how those two concepts can be married together. A GraphQL Web service can have different Query and Mutation objects, based on the identity (or lack thereof) of whoever is making the GraphQL request.

So, for example:

One pattern that has emerged in this area is to have an object be available through the Query — typically named viewer — that represents what the authenticated user has access to. What server-defined type the viewer is might vary based upon the user whose authentication credentials were used.

This context-sensitive schema can complicate static GraphQL development, where tools like Apollo-Android want access to the schema for code-generation purposes. If there are unknowable numbers of schemas, based upon uncountable combinations of roles, it may be difficult to figure out how to make Apollo-Android and similar tools happy. For accessing your own server, you may be able to craft some all-powerful account that represents the superset of all possible capabilities, then generate a schema from it.

Exploring GitHub’s Approach

The preview of this section is sleeping in.