GraphQL with Python — Part-1

In today’s time programmers are using different programming languages which serve requirements from multiple sources like Postgres, Redis, etc. Developers are using REST APIs to serve that purpose. So, let’s first understand what challenges are faced by using REST.

Challenges in modern application:

• Hard to manage versions single request due to changes in response schema or structure
• Required many resources because of fix response with fix endpoints
• Distinct front-end clients for multiple platforms (web, iOS, etc.), each with different data requirements
• A backend that serves data to clients from multiple sources (Postgres, Redis, etc.)
• Complex state and cache management for both the frontend and the backend

What is GraphQL ?

GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.

GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015.

In today’s world GraphQL is used by many leading companies like,

• coursera
• Airbnb
• GitHub
• PayPal
• Starbucks
• Shopify
• Twitter

and many more …

Features of GraphQL:

• Ask for what you need,get exactly that
  Send a GraphQL query to your API and get exactly what you need, nothing more and nothing less. GraphQL queries always return predictable results. Apps using GraphQL are fast and stable because they control the data they get, not the server.
• Get many resources in a single request
  GraphQL queries access not just the properties of one resource but also smoothly follow references between them. While typical REST APIs require loading from multiple URLs, GraphQL APIs get all the data your app needs in a single request. Apps using GraphQL can be quick even on slow mobile network connections.
• Describe what’s possible with a type system
  GraphQL APIs are organized in terms of types and fields, not endpoints. Access the full capabilities of your data from a single endpoint. GraphQL uses types to ensure Apps only ask for what’s possible and provide clear and helpful errors. Apps can use types to avoid writing manual parsing code.

GraphQL provide single Endpoint for everything you need

You might be wondering how to know which data are available using only one Endpoint? The answer is schema.

Schema

Schemas define what kind of data can be queried from a service. Schema consists of a set of types defined to describe the data. Each type might have one or more fields.

The most basic components of a GraphQL schema are object types, which just represent a kind of object you can fetch from your service, and what fields it has. In the GraphQL schema language, we might represent it like this:

type TblPost {
post_id: ID!
title: String!
description: String!
}

TblPost is a GraphQL Object Type, meaning it’s a type with some fields.

post_id, title and description are fields on the TblPost type. That means those are the only fields that can appear in any part of a GraphQL query that operates on the TblPost type.

! means that the field is non-nullable, meaning that the GraphQL service promises to always give you a value when you query this field.

GraphQL comes with a set of default scalar types out of the box:

Int: A signed 32-bit integer.

Float: A signed double-precision floating-point value.

String: A UTF-8 character sequence.

Boolean: true or false.

ID: The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache.

Queries and Mutations

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

Queries are used for fetch data fetching which is basically GET of REST.

Let’s look at a simple example query:

Query:
type Query {
getPost(post_id: ID!): PostResult!
}
Schema :
query GetPost {
   getPost(post_id: "1") {
   post {
     post_id
     title
     description
   }
   success
   errors
 }
}

Most discussions of GraphQL focus on data fetching, but any complete data platform needs a way to modify server-side data as well.

In REST, any request might end up causing some side-effects on the server, but by convention it’s suggested that one doesn’t use GET requests to modify data. GraphQL is similar — technically any query could be implemented to cause a data write. However, it’s useful to establish a convention that any operations that cause writes should be sent explicitly via a mutation.

Just like in queries, if the mutation field returns an object type, you can ask for nested fields. This can be useful for fetching the new state of an object after an update. Let’s look at a simple example mutation:

Mutation:
type Mutation {
   updatePost(post_id: ID!): PostResult!
}
Schema:
mutation UpdatePost {
  updatePost(
    post_id: "3"
    title: "Hello title"
    description: "updated description"
  ) {
    post {
      post_id
      title
      description
    }
    success
    errors
  }
}

Libraries and Tools for GraphQL in Python:

• Ariadne
• Graphene
• Strawberry
• Tartiflette

Ariadne:

Ariadne is a lightweight Python library that lets you get up and running with GraphQL quickly.

Ariadne is framework agnostic (which means you can use it with Flask, Django, or any other framework of your choice) and it uses a schema first approach to GraphQL API development.

In this approach, we define our schema first (as we did for this demo app) and write the business logic based on our schema.

Another popular pattern is to use a code first approach while designing GraphQL APIs (Graphene is a popular library that does this).

So, let’s understand what is schema first and code first.

Schema-First

Schema-first indicates that we first define the schema for the GraphQL service and then we implement the code by matching the definitions in the schema. To code the schema, we use the Schema Definition Language (SDL), a syntax created to represent the GraphQL data model. Because of this, this approach may also be called SDL-first.

Code-first

In the code-first approach, we start by coding the resolvers, and then, from code as a single source of truth, we have the schema generated as an artifact. Thus, we still have a schema, but instead of being manually created, it is created through running a script. This approach may also be called resolver-first.

We will go through Demo code in Part-2 of GraphQL series. Stay Tuned !

I hope this will be helpful to understand basic about GraphQL.

Happy Coding !!!