Understanding schema in GraphQL

Reading Time: 3 minutes

The world is a stage where all of us are artists. Constant learning is the foundation of success. To boost up your knowledge pot with various technology, here comes another blog about a developing technology GraphQL.
GraphQL is a query language introduced by Facebook. To get in basic detail you can visit previous blogs. Here we will discuss about Schema.
Also, if you want to start the basics and explore GraphQL from scratch, please refer to my previous blogs here and here.

Schema

The GraphQL schema is the centre of any GraphQL server. It defines the server’s API, allowing clients to know about which operations can be performed by the server. GraphQL has its own type system that’s used to define the schema of an API. The syntax for writing schemas is called Schema Definition Language (SDL). We can use many programming language to create a GraphQL schema.

Every GraphQL service has a query type and may or may not have a mutation type. These may look same as a regular object type, but they are special as they define the entry point for all GraphQL query.

A query is used to read or fetch values while a mutation is used to write or post values. In either case, the operation is a simple string that a GraphQL server can parse and respond to with data in a specific format.

A schema is resolved by using DataFetchers. With help of datafetcher we are able to interact the code with schema.

A normal GraphQL query looks like this:

type Query {
   student:String
}

type Mutation {
   createStudent(collegeId:ID,firstName:String,lastName:String):String
}

Types

GraphQL supports the following kind of types:

  • Scalar
  • Object
  • Interface
  • Union
  • InputObject
  • Enum
Scalar

The most basic type is a Scalar. A scalar represents a primitive value, like a string or an integer. Type systems can also help in adding additional scalars. 
GraphQL provides a number of built‐in scalars(String, Boolean, Int, Float, ID).
Scalar looks like:

  id: ID!
  number: String
  name: String
  book: Book
Object

It is generally group of scalars. Objects represent a list of named fields, each of which yield a value of a specific type.
Object looks like:

type Books {
  name: String
  id: Id
  author: Author
}
Interface

Interfaces consist of list of named fields and their arguments.
Objects implement these interfaces which requires that the object type will be defined by those interfaces.
eg.

interface Author {
  authorName: String
}

interface Price {
  value: Int
}

type Book implements Author {
  bookName: String
  authorName: String
}

type Book implements Author & Price {
  bookName: String
  authorName: String
  value: Int
}
Union

Union consist of more than one object. So when it encounter with either of those object it can interact flawlessly. But if it encounter with a object which consist both objects fields, it will not wok.
eg.

    type Cat {
        name: String;
        lives: Int;
    }

    type Dog {
        name: String;
        bonesOwned: int;
    }

    union Pet = Cat | Dog

  type FindQuery {
       searchResult: Pet
     }

to query for this the right way is:

{
    searchResult {
    ... on Cat {
      name
    }
    ... on Dog {
      bonesOwned
    }
  }
}
Enum

Enums references unique values in their own right. They may serialize as a string.
eg.

enum Color {
        RED
        GREEN
        BLUE
    }
Input Objects

Input Object defines a set of input fields.
The input fields can be either scalars, enums, or other input objects.
This allows arguments to accept arbitrarily complex structs.
Object types can contain fields that define arguments or contain references to interfaces and unions. So, objects can’t be used in Input Type.
eg.

input Circle {
  pie: Float
  r: Float
}

That’s pretty much it from the article. If you have any feedback or queries, please do let me know in the comments. Also, if you liked the article, please give me a thumbs up and I will keep writing blogs like this for you in the future as well. Keep reading and Keep coding.

Reference

Knoldus-blog-footer-image