Introduction to GraphQL

Vlad Antsitovich
5 min readFeb 16, 2022

In this article, we going to find out what is exactly is GraphQL.

What is the graph?

A graph is a data structure that consists of a set of nodes and a set of edges that relate the nodes to each other.

Graph has:

  1. Nodes — individual pieces of data
  2. Edges — relationships between pieces of data

What is GraphQL?

GraphQL is a specification that describes: a query language and schema definition language. It’s not a programming language capable of arbitrary computation, but is instead a language used to make requests to application services that have capabilities defined in this specification.

GraphQL is a graph query language for your API and a server-side runtime for executing queries using a type system you define for your data. It’s not how you implement a server or it’s not a client implementation, but it’s more a specification of how those two can talk to each other.

GraphQL is data source-agnostic. This means that you can use whatever database technology you like to fetch and save data; for instance — SQL, ORMs, NoSQL, JSON, or in-memory data all work just fine. GraphQLapplications consist of two primary components: a schema of type definitions and resolvers, which resolve the queries and mutations performed against the data.

ℹ️ Basically GraphQL just:

  • A type system
  • A formal language for queries
  • Rules for validation and executing a query against a schema

GraphQL provides a complete description of the data in your API, and you can only request the exact data you need and nothing more. It also makes it easier to improve APIs if they need it and has very powerful developer tools.

ℹ️ The main parts of GraphQL:

  • Type Definitions
  • Resolvers
  • Schema — the combination of Type Definitions and Resolvers
  • Data Sources — get data from third-party resources (REST services or DataBases)
  • Queries — what clients use to read data from a GraphQL server
  • Mutations — what client use to mutate data

Why GraphQL?

GraphQL helps us go faster, it lets you say goodbye to all the old REST endpoints and back-end for front-end code and intricate state management code that costs so much to build and keep slowing you down. Graph lets you replace all that stuff with a schema a universal API that lets you build new features and a richer more engaging experience with far less work and in far less time.

As you build your schema what you’re really doing is creating a virtual representation of all your data, services and capabilities.

GraphQL lets you ask for information about what’s in your graph and how it’s connected. Which is defined by the schema along with types and the relationships between your pieces of data.

How do we use GraphQL?

Schema

Schema is a definition of every type of node available to you and what properties it has. The basic thing the schema does is define what it’s possible to ask for. It’s often written in a language called schema definition language which is pretty similar to TypeScript which is a thin typing layer on top of JavaScript.

Here is part of the schema:

type User {
id: ID!
name: String!
email: String
isActive: Boolean!
}

And you can notice that this part of the schema is all about defining types.

Types

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. The ID type is serialized in the same way as a String; however, defining it as an ID signifies that it is not intended to be human‐readable.

It’s called scalar types — the building blocks of the type system.

In most GraphQL service implementations, there is also a way to specify custom scalar types. For example, we could define a Date type:
scalar Date

Then it’s up to our implementation to define how that type should be serialized, deserialized, and validated. For example, you could specify that the Date type should always be serialized into an integer timestamp, and your client should know to expect that format for any date fields.

GraphQL types are nullable by default.

Operations in GraphQL

There are 3 types of operations:

  1. Query — a read-only fetch (get data).
  2. Mutation — a write followed by a fetch (mutate data).
  3. Subscription — a long-lived request that fetches data in response to source event.

GraphQL queries run in parallel, mutations run one after another.

You can use operations to specifically ask for exactly the data you need and receive only that data back.

Why GraphQL could be a bad fit?

Uploading files

How to deal with this?
Upload to something that returns a URL where an image will store then send the URL to your graph using GraphQL

No versioning

If we want to remove things we need to deprecate this thing and your team needs to still has to look at the actual usage of this deprecated thing and wait until nobody is actually asking for this field anymore before actually saying goodbye to that field.

Simple security

You need to think more granularly about security.

The fact that GraphQL only gas one endpoint means that you are not going to be able to just return a 401 status code. You’re going to have to think on a more field-by-field basis about who should have access to what and work with the back-end team to make sure that it works well for everyone.

Schema introspection is by default unprotected. This means that anyone who knows the way to query a GraphQL server to return information about its schema can get your schema really easily.

Sources:

--

--