Client-side GraphQL schema resolving and schema-stitching

This blogpost talks about the why and how of:

1. Using GraphQL on the client by mapping GraphQL to REST APIs
2. Using multiple GraphQL APIs on the client with schema-stitching
3. Without building a GraphQL server

TL;DR:

Head to this github repo-tutorial to see how to setup a GraphQL schema, resolvers and schema-stitching on your client.

In the journey to GraphQL, mainly for existing applications, a few common approaches are emerging:

1. GraphQL gateway service that proxies to REST
2. GraphQL gateway service that stitches different GraphQL schemas served by different services into one

1 is common when you already have REST endpoints that you want to make API calls to and the team cannot invest in writing a GraphQL backend that runs business logic and queries data-sources.

2 is common when you’re using different GraphQL services on the backend and want to present a unified GraphQL endpoint as opposed to multiple ones.

However, in a lot of cases, when moving to GraphQL the app dev team might not be able to create their own backend service because of the increase in operational effort and process that this might require.

Is it then worth doing GraphQL on the client only, without needing a GraphQL server?

GraphQL on the client will nullify 2 traditionally espoused GraphQL benefits:

1. Reduced API calls
2. Lesser data on the network

But, even without these 2 benefits, GraphQL only on the client-side only (esp. with React) does have some real benefits.

GraphQL improves UI architecture:

Tyler’s lists motivations in his talk “GraphQL outside the box” where he built GraphQL on the client because the benefits of GraphQL on the UI architecture were very real:

1. A better data layer: Mapping remote data to the client-side shape becomes easier with GraphQL and using Apollo’s react client
2. Better component APIs: UI components can use GraphQL types, components can describe their static data dependencies as GraphQL fragments
3. Data modelling upfront: Using GraphQL in your client involves that you think about your GraphQL types first and makes the data-modelling step explicit.

Incremental migration

Setting up a GraphQL backend might take time, especially for legacy applications and GraphQL on the client represents a neat incremental step.

As we are working with users of the Hasura GraphQL engine, we noticed that similar problems were emerging, especially developers working in environments where building a new backend service is not feasible.

Working with them we created a simple tutorial, using the existing community tooling, that allows a GraphQL schema and resolver to be written on the client itself.

1. A Typical GraphQL setup:

2. A client side GraphQL setup:

3. How to build GraphQL on the client

Rishichandra Wawhal has put together a tutorial as a github repo of how to use Apollo schema-link, graphql-js and other tools from the nodejs ecosystem to be able to do client-side graphql using Apollo client.

1. Write a GraphQL schema and resolvers using graphql-tools
2. If required, set up schema stitching with graphql-tools
3. Use schema-link to make Apollo client query the schema directly instead of using fetch.

// Create a GraphQL schema and resolvers

import { makeExecutableSchema } from 'graphql-tools';
const typeDefs = `
  type Hello {
    message: String
  }
`;
const resolvers = {
  Query: {
    message: (root, args, context, info) => "hello-world"
    // Or make a remote API call
  }
};
const schema = makeExecutableSchema({
  typeDefs,
  resolvers
});

// Setup Apollo client as usual, but use SchemaLink
import { SchemaLink } from 'apollo-link-schema';
import { InMemoryCache } from 'apollo-cache-inmemory';
import ApolloClient from 'apollo-client';
const client = new ApolloClient({
  link: new SchemaLink({ schema }),
  cache: new InMemoryCache()
})

Next on the roadmap is to add subscription support per: https://github.com/apollographql/apollo-link/issues/374