Skip to main content

On GraphQL and building an application using React Apollo

When I visualize building an application, I would think of using React and Redux on the front-end which talks to a set of RESTful services built with Node and Hapi (or Express). However, over a period of time, I've realized that this approach does not scale well when you add new features to the front-end. For example, consider a page that displays user information along with courses that a user has enrolled in. At a later point, you decide to add a section that displays popular book titles that one can view and purchase. If every entity is considered as a microservice then to get data from three different microservices would require three http requests to be sent by the front-end app. The performance of the app would degrade with the increase in the number of http requests.

I read about GraphQL and knew that it is an ideal way of building an app and I need not look forward to anything else. The GraphQL layer can be viewed as a facade which sits on top of your RESTful services or a layer which can be used to talk directly to the persistent layer. This layer provides an interface which allows its clients (front-end apps) to query the required fields from various entities in one single http request.

GraphQL - On the Server

On the server side, GraphQL provides a schema language using which you can construct the domain model. In GraphQL terms, these are `types`, a `type` is used to represent an entity such as User, Course, Book etc. It looks something like this:

type CourseType {
    id: ID!
    name: String
    level: Int
    description: String

Here, each field in CourseType entity has a type indicating the value that it can hold (String, Float, Character, Int etc). Apart from the Scalar types, a field could also be used to declare the relationship between two types. For example, a StudentType can have a field `courses` to declare the courses that he/she has enrolled in:

type StudentType {
     id: ID!
     firstName: String
     lastName: String
     courses: [CourseType]!

Here the field `courses` is of type `[CourseType]!`. The array notation is used to indicate that a Student record can have a collection of courses i.e. a student can enrol in multiple courses(1-to-many relationship). The bang (!) is used to indicate that it's a required field.

Apart from defining types, one is required to specify what can be retrieved using a `Query` and what can be updated using `Mutation`.

type Query {
    allCourses: [CourseType]
    allStudents: [StudentType]

type Mutation {
    createCourse(name: String, level: Int, description: String): CourseType
    createStudent(firstName: String, lastName: String, courses: [CourseType]!): StudentType
    updateCourse(id: ID!, name: String, level: Int, description: String): CourseType

Here types `Query` and `Mutation` are special types. They're not used to define an entity, rather they're used to specify the operations that you can perform on these entities. For example, `allCourses` in `Query` is used to declare that the client can use this to retrieve a list of courses (returns [CourseType]). A Mutation type, on the other hand, is used to indicate the operations that you can perform to update these entities. In the above example, createCourse, createStudent etc are the operations that you can perform to add or update records.

All the above types put together come to form the type definition for your schema and it gives a high-level overview of the domain model and the operations that you could perform on various entities. However, the business logic for how the data would be retrieved or updated is not present. To accomplish this, one is required to write resolvers. A resolver provides the implementation that maps to the operations declared in the schema. A sample resolver for the above example looks like this:

const resolvers = {
    Query: {
        allCourses: () => {
            return COURSES;
    Mutation: {
        createCourse: (_, { input }) => {
            let { id, name, description, level } = input;
            return input;

The resolvers object contains two properties Query and Mutation; under these, you would define the various operations that can be performed on the entities declared in the schema. Note, that the name of the operations would map to the ones specified in the schema (here allCourses in type Query and createCourse in type Mutation). The type definitions are independent of the language or the platform that you choose. However, the resolvers are written in the language of your choice; in this case JavaScript.

The type definitions and resolvers come together to define the executable schema which can then be used to define middleware in a Node + Express environment:

const schema = makeExecutableSchema({ typeDefs, resolvers});

I've used `graphql-tools` and `apollo-graphql-express` modules to create the schema and the middleware which would accept incoming requests.

To test the server setup, you could make use of the GraphiQL interface which allows you to inspect the operations declared in the schema, add this:

                  endpointURL: '/graphql'

The graphiql interface provides us with a way to test the operations declared in `Query` and `Mutation` of our schema:

Here, the object notation on the left side allows me to specify the query method and the fields that I need from the `courses` model (id and name). The response from the server (on the right side) includes only the data that I have requested. Although the resolver itself returns the entire object, GraphQL ensures that only the requested data is returned in the response; thus reducing the size of the payload.

GraphQL - On the client side

On the client side, the first step would be to connect to the GraphQL server and wrap the root component with the Provider (ApolloProvider from `react-apollo`):

import React from 'react';
import ReactDOM from 'react-dom';
import { ApolloProvider } from 'react-apollo';
import { ApolloClient } from 'apollo-client';
import { HttpLink } from 'apollo-link-http';
import './index.css';
import App from './App';

const client = new ApolloClient({
    link: new HttpLink({ uri: 'http://localhost:8080/graphql' })

    <ApolloProvider client={client}>
        <App />

Next, we use the `react-apollo` module which provides a higher-order function using which we can glue together a component with the result from a GraphQL query response:

import React, { Component } from 'react';
import { graphql } from 'react-apollo';
import gql from 'graphql-tag';
import Course from './Course';

class CourseList extends Component {
    render() {
        const { allCourses } =;
        if (!allCourses) return null;
        return => {
            return (
                <Course key={}
                              course={course} />

export default graphql(gql`
    query CourseListQuery {
        allCourses {

Here the graphql higher-order function accepts two arguments - the GraphQL query and the view component that has to be updated with the query result. The result of the query response is passed to the component as props (

Next steps:

I've briefly read about `Relay` and I plan to experiment with it to see how it can be used to connect to a GraphQL server and compare it to see how it fairs with Apollo. 

GitHub repo


Popular posts from this blog

Custom validation messages for HTML5 Input elements using the constraint validation API

HTML5 has introduced several input types such as EMAIL, URL, RANGE, SEARCH, DATE, TIME, etc,. Most of the modern browsers have implemented them and are ready to be used in a HTML document. Another exciting feature introduced in HTML5 is the form validation. Instead of writing JavaScript to validate users input, browsers can now validate it and show an appropriate message if the validation fails. The validation message is shown in line with the field for which the validation has failed. The default error message is shown when the validation fails. In this post I'll explain how these error messages can be changed.

Adding beforeRender and afterRender functions to a Backbone View

I was working on a Backbone application that updated the DOM when a response was received from the server. In a Backbone View, the initialize method would perform some operations and then call the render method to update the view. This worked fine, however there was scenario where in I wanted to perform some tasks before and after rendering the view. This can be considered as firing an event before and after the function had completed its execution. I found a very simple way to do this with Underscore's wrap method.

A cheat sheet of keyboard shortcuts in ColdFusion Builder

In my last post I have explained about keyboard shortcuts in ColdFusion Builder 2.0. This blog post contains a list of all shortcut keys and I have listed these keyboard shortcuts based on the categories that it falls into. Well, this post was not planned since users can easily get to know the keyboard shortcuts by navigating to the preferences (ColdFusion -> Profiles -> Keys). However, I met Joshua at Scotch on the rocks in Edinburgh and he suggested that it would be nice to have the list of keyboard shortcuts handy. So this post is for those who would like to have the list with them and refer it whenever required.

Keyboard shortcuts for inserting text:

These are the keyboard shortcuts which are used to insert some text into the editor:

CommandKeyboard shortcuts on WindowsKeyboard shortcuts on MacInsert anchor tagCTRL + T, LCMD + T, LInsert bold tagCTRL + T, BCMD + T, BInsert br tagCTRL + T, RCMD + T, RInsert cfabortCTRL + T, ACMD + T, AInsert cfdumpCTRL + T, DCMD + T, DInsert cfs…