In this post we will first try to understand what is graphql. This blog could be long but i will try to explain GraphQL from a beginners point of view
P.S. GraphQL is an advanced concept, so its understood that you are aware of concepts like rest api’s, frontend/backend technologies.
What is it
GraphQL is a query language or in a way to structure your api’s on backend, frontend. It’s a new way in which you should write your backend and also a different way to call api’s from frontend. It’s not a language but rather pattern to structure your api’s for both frontend/backend. Hence graphql can be applied to any existing languages like nodejs, php, python, etc and also any frontend frameworks.
REST API
I assume most of you reading this blog are aware of rest api as this is the standard we have been using till now.
GraphQL is a not a language, its a design pattern. Similar to REST API, its a concept on how we can design our backend apis. It’s basically an alternate to rest api, so it’s a concept on how we should structure our api’s
In REST API, we have resources e.g if we have an entity user for which we can GET, POST, PUT, DELETE to fetch, add, update, delete respectively.
In GraqhQL we have “queries” and “mutations” perform these operations.
Queries are used for fetch related to operations and mutations to perform “add”, “update”, “delete”
Why GraphQL
Let’s try to understand why we need GraphQL in the first place.
There have two major trends a) frontend framework like React, Angular, Vue are used almost everywhere for websites/mobile apps b) NoSQL/Cloud database solutions like mongodb, firebase, dynamodb etc and many simlar database support json data structures rather than traditional mysql tables
Both these frontend/backend technology we see they have one thing in common, a tree structure of entities. For frontend framework we organize our components in a tree structure and even our database we store data in tree structure.
For Backend
In our tradition db like mysql there is no concept of tree structures. We have different tables with relations via primary keys/foreign keys.
Let’s take an example, suppose we have entities/attributes like
User -> username, password
Profile -> firstname, lastname, email
Address -> street, pincode, state
Role -> role
Let’s see how we would structure this in a tradition database like mysql
user table
=============================
id - (primary key)
username - (string)
password - (string)
profile table
===============
id - (primary key)
user_id - (foreign key)
firstname - (string)
lastname - (String)
email - (string)
address table
===============
id - pk
user_id - fk
street - (string)
pincode - (string)
....
role table
=============
id - pk
role - string
user_role table
==================
id - pk
user_id - fk
role_id - fk
above is typical structure for mysql tables but this is will be not a typical structure of a cloud db (nosql). Let’s also look at REST API for above and see why it makes sense to go with rest api for traditional db’s
POST /api/login REQ {username,password} RES token
entity user
POST /api/user REQ (username,password} RES 200
PUT /api/user/:user_id
GET /api/user/:user_id
DELETE /api/user/:user_id
POST /api/user/address REQ (user_id, firstname, lastname, email)
GET /api/user/address/:user_id
PUT /api/user/address/:user_id/:address_id
DELETE /api/user/address/:user_id/:address_id
POST /api/user/assign_role/:user_id/:role_id
PUT /api/user/update_role/:user_id/:role_id
As we can see above all our rest api’s are also designed in the same way i.e api for every entity/resource, access then via id’s so this fits perfectly.
Now let’s see how we would or should design the the same database structure in database like firebase or mongodb.
user collection/document
===========================
{
id,
username,
password,
{
profile: {
firstname,
lastname,
}
},
address: {
[
{street, pincode},
{street, pincode}
]
},
role: ..... // role_id
}
role collection/document
{
id,
name
}
As we see, in a nosql database the structure is totally different we define relationship in a tree structure of nested json rather then different tables.
Read more about how to structure data here
https://firebase.google.com/docs/database/admin/structure-data
https://docs.mongodb.com/guides/server/introduction/
Now if we start to model our rest api’s to this data structure we face problem. It just doesn’t fit! Hence GraqhQL!
P.S. Many time it’s seen that due to how rest api is structure, please try to use nosql database in a relational database structure. Like fine collections for users, profile, address having invidual id’s and relationship. That’s it not the correct way to define a nosql db as we can see from official docs. But rest api forces us many times to define it in such a way.
For Frontend
Let’s take any frontend framework like React, Vue, Angular all follow nested component structure. We will look at the same entity structure. Let see we want to display a user’s data on a page, we would design our components like this
UserComponent
---> Profile Component
---> [ Address Component ]
---> Role
You could argue that since it’s such a small data i would just have one single component but let’s think for a large system with a complex UI, we would automatically break it down into small components.
Now if we have a rest api structure we would typically call api’s when components loaded and pass the respective id’s. So we would have in total 3 GET requests to load data for each component.
GraphQL solves this by haveing a single Query or clubbing multiple queries together if needed in a single call, and giving frontend developer option on how we wants to manage/structure the data.
Till now we saw how graphql solves but now let’s see it in practice and understand some of the basic concepts of graphql.
Next blog follows!