ZEMOSO ENGINEERING STUDIO
June 5, 2022
12 min read

GraphQL — Why is it essential for agile product development?

For most digital products, communication between the Client and Server is one of the most vital parts. Over the years, there have been many attempts to make this more efficient and streamlined. 

RPC, an old school approach

One of the first approaches for handling client-server communication is Remote Procedure Calls (RPC). Here, the client calls a function/procedure on the server through the request.

 Example of a RPC to-do list application
Example To-do list application

As an example, consider a to-do list application. A user using this application can create/view “lists.” A list can contain a set of “Items.” Users can add/delete “items” in the “list,” and move an “item” from one “list” to another.

Challenges with RPC

There are a few challenges with this approach,

● Exposing the functions and implementation details to the client introduces tight coupling between client and server code. Every time a change is to be made on the server, the corresponding client code should be updated as well.

● Another issue is discoverability. There's no direct way for the client to know that a given Application Programming Interface (API) exists. Usually, supporting external documentation outlining such details will have to be shared.

● For each specific requirement, one could end up adding a new function on server-side code, which will return the exact data required by the client. But such a practice will soon result in something called “function explosion”. Where there are numerous unnecessary functions in the server side code, each of which is useful to one specific request.

REST

In 2000,  REpresentational State Transfer (REST) was introduced.

The main idea in REST is that any information that needs to be exposed to the client will be abstracted as a resource. The client can view/update the state of these resources through requests to the server.

To refer to an interface as RESTful six constraints must be satisfied.

1.    Client-server

2.    Uniform interface

3.    Stateless

4.    Cacheable

5.    Layered System

6.    Code on demand

Example to-do app: REST approach

Let us design the same to-do application now with REST. First, we have to identify the objects in our domain and represent them as resources. Here list and item are good choices for resources to be exposed through API. The set of API calls mentioned above will transform as follows.

●    GET /lists

●    GET /lists/42/items

●    POST /lists/42/items

●    DELETE /items/24

GET /lists fetches all the lists. GET/lists/42/items fetches all the items in a list with id 42 and so on. There's no tight coupling, and the client will be able to navigate through the APIs using hyperlinks provided.  

Problems with REST

● Large payloads: A RESTful API will always respond with a resource. All the fields in a resource may or may not be relevant to the client all the time. Thus, the client will end up processing a large payload.

● Increased round trips between client and server: A client could end up making multiple requests to the server to fetch relevant data. This will increase the number of requests to the server and could affect the performance of both the server and client.

On a powerful device connected to a high-speed network, both of these problems are hardly noticeable.

But,  when a user on a mobile device tries to get something from the application, the above problems will throttle performance and make the application unusable.

This was the exact problem engineers at Facebook faced in 2012, and the project they undertook to solve the problem evolved into  “GraphQL”.

What is GraphQL?

To quote the official documentation

GraphQLis a query language for APIs and a runtime for fulfilling those queries with your 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 is an alternative approach to client-server communication. It is a specification, which outlines the structure and behavior of request and response that are to be exchanged between a client and a server.

GraphQL doesn't mandate a particular programming language or storage system for application servers that implement it.  There are numerous implementations of GraphQL in various languages/frameworks.

It facilitates efficient and effective communication between client and server.

In the initial stages, GraphQL’s main goal was to tackle the problems of large payloads and multiple round trips. It solves this problem by giving clients the power to ask for exactly what they need and nothing more.

Example to-do app: GraphQL approach

Let us consider the to-do app example, again. We have the same requirement: client wants to know the “name” field of the first item in the second list in application. With GraphQL, the contents of the request and response exchanged through API calls could look as follows:

Contents of GraphQL request sent from the client
Contents of GraphQLrequest sent from the client
 Contents of GraphQL response from server
Contents of GraphQLresponse from server

The client sent only one request to the server, and received one response, which contained the exact required field. Value for the field is “Write” as we can see in the above example.

Since the client can ask what it wants and get exactly what it needs in a single round-trip both the problems of processing large payloads and multiple round trips are avoided here.

We used a query type request; these are used for reading the data. The query accepts an optional argument; if optional arguments are present, the server could use them to narrow the search and filter the data. Here, we're interested in the second list only. Thus we pass positions:[1] when communicating our requirements to the server.

Inside the list, we only mentioned items; this will inform the server that we are only interested in that field and other fields aren't required. Items field accepts an optional parameter position, which is an array. We're interested only in the first item; thus we pass positions[0].Inside items, we mention name; this cues the server that it should include only the name field in the response.

Here is a comparison graphic to summarize our discussion:

Comparison with RPC, REST and GraphQL

When should one use GraphQL? 

GraphQL is a robust approach and a very good choice for certain scenarios. Unfortunately, there's no one-size-fits all answer, but we've seen GraphQL work in most scenarios.

To determine the best approach for your product development, you must ascertain which guarantees are essential and intolerable constraints on your API design.

GraphQL is an especially good choice when designing a mobile-first user experience. It helps erode response delays with limited computing power and slower networks, making for a better user experience.

GraphQL simplifies querying with complex schemas, and improves developer productivity.

Caveats with GraphQL

Like any other solution, GraphQL has a few constraints.

Using GraphQL you can request and receive only the relevant data; this is achieved by moving the responsibility of “getting the relevant data” from the client onto the server.

Instead of the client parsing a large payload, the server now parses a relatively complex request. Depending on the request, the server will hit the database (multiple times if needed) and aggregate all the relevant data that was requested. The server then prepares the response as per the request and sends it back to the client.

Although the client here's doing less work, the back-end is doing more work. If you engineered your system correctly, the amount of processing work done by the back-end only increases moderately. If you didn’t follow best practices, the number of calls between server and database could increase and slow down performance.

It’s tricky, often requiring customized engineering effort, to handle coaching, authorization, versioning, and pagination effectively.

Getting GraphQL right is hard.

A successful example of a large-scale application using GraphQL in production is GitHub’s switch from API to GraphQL. They maintain a GraphQL explorer for their API, through which one could explore production data in real-time.  

An earlier version of this blog was published on Medium by the author.

ZEMOSO ENGINEERING STUDIO

GraphQL — Why is it essential for agile product development?

April 30, 2019
12 min read

For most digital products, communication between the Client and Server is one of the most vital parts. Over the years, there have been many attempts to make this more efficient and streamlined. 

RPC, an old school approach

One of the first approaches for handling client-server communication is Remote Procedure Calls (RPC). Here, the client calls a function/procedure on the server through the request.

 Example of a RPC to-do list application
Example To-do list application

As an example, consider a to-do list application. A user using this application can create/view “lists.” A list can contain a set of “Items.” Users can add/delete “items” in the “list,” and move an “item” from one “list” to another.

Challenges with RPC

There are a few challenges with this approach,

● Exposing the functions and implementation details to the client introduces tight coupling between client and server code. Every time a change is to be made on the server, the corresponding client code should be updated as well.

● Another issue is discoverability. There's no direct way for the client to know that a given Application Programming Interface (API) exists. Usually, supporting external documentation outlining such details will have to be shared.

● For each specific requirement, one could end up adding a new function on server-side code, which will return the exact data required by the client. But such a practice will soon result in something called “function explosion”. Where there are numerous unnecessary functions in the server side code, each of which is useful to one specific request.

REST

In 2000,  REpresentational State Transfer (REST) was introduced.

The main idea in REST is that any information that needs to be exposed to the client will be abstracted as a resource. The client can view/update the state of these resources through requests to the server.

To refer to an interface as RESTful six constraints must be satisfied.

1.    Client-server

2.    Uniform interface

3.    Stateless

4.    Cacheable

5.    Layered System

6.    Code on demand

Example to-do app: REST approach

Let us design the same to-do application now with REST. First, we have to identify the objects in our domain and represent them as resources. Here list and item are good choices for resources to be exposed through API. The set of API calls mentioned above will transform as follows.

●    GET /lists

●    GET /lists/42/items

●    POST /lists/42/items

●    DELETE /items/24

GET /lists fetches all the lists. GET/lists/42/items fetches all the items in a list with id 42 and so on. There's no tight coupling, and the client will be able to navigate through the APIs using hyperlinks provided.  

Problems with REST

● Large payloads: A RESTful API will always respond with a resource. All the fields in a resource may or may not be relevant to the client all the time. Thus, the client will end up processing a large payload.

● Increased round trips between client and server: A client could end up making multiple requests to the server to fetch relevant data. This will increase the number of requests to the server and could affect the performance of both the server and client.

On a powerful device connected to a high-speed network, both of these problems are hardly noticeable.

But,  when a user on a mobile device tries to get something from the application, the above problems will throttle performance and make the application unusable.

This was the exact problem engineers at Facebook faced in 2012, and the project they undertook to solve the problem evolved into  “GraphQL”.

What is GraphQL?

To quote the official documentation

GraphQLis a query language for APIs and a runtime for fulfilling those queries with your 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 is an alternative approach to client-server communication. It is a specification, which outlines the structure and behavior of request and response that are to be exchanged between a client and a server.

GraphQL doesn't mandate a particular programming language or storage system for application servers that implement it.  There are numerous implementations of GraphQL in various languages/frameworks.

It facilitates efficient and effective communication between client and server.

In the initial stages, GraphQL’s main goal was to tackle the problems of large payloads and multiple round trips. It solves this problem by giving clients the power to ask for exactly what they need and nothing more.

Example to-do app: GraphQL approach

Let us consider the to-do app example, again. We have the same requirement: client wants to know the “name” field of the first item in the second list in application. With GraphQL, the contents of the request and response exchanged through API calls could look as follows:

Contents of GraphQL request sent from the client
Contents of GraphQLrequest sent from the client
 Contents of GraphQL response from server
Contents of GraphQLresponse from server

The client sent only one request to the server, and received one response, which contained the exact required field. Value for the field is “Write” as we can see in the above example.

Since the client can ask what it wants and get exactly what it needs in a single round-trip both the problems of processing large payloads and multiple round trips are avoided here.

We used a query type request; these are used for reading the data. The query accepts an optional argument; if optional arguments are present, the server could use them to narrow the search and filter the data. Here, we're interested in the second list only. Thus we pass positions:[1] when communicating our requirements to the server.

Inside the list, we only mentioned items; this will inform the server that we are only interested in that field and other fields aren't required. Items field accepts an optional parameter position, which is an array. We're interested only in the first item; thus we pass positions[0].Inside items, we mention name; this cues the server that it should include only the name field in the response.

Here is a comparison graphic to summarize our discussion:

Comparison with RPC, REST and GraphQL

When should one use GraphQL? 

GraphQL is a robust approach and a very good choice for certain scenarios. Unfortunately, there's no one-size-fits all answer, but we've seen GraphQL work in most scenarios.

To determine the best approach for your product development, you must ascertain which guarantees are essential and intolerable constraints on your API design.

GraphQL is an especially good choice when designing a mobile-first user experience. It helps erode response delays with limited computing power and slower networks, making for a better user experience.

GraphQL simplifies querying with complex schemas, and improves developer productivity.

Caveats with GraphQL

Like any other solution, GraphQL has a few constraints.

Using GraphQL you can request and receive only the relevant data; this is achieved by moving the responsibility of “getting the relevant data” from the client onto the server.

Instead of the client parsing a large payload, the server now parses a relatively complex request. Depending on the request, the server will hit the database (multiple times if needed) and aggregate all the relevant data that was requested. The server then prepares the response as per the request and sends it back to the client.

Although the client here's doing less work, the back-end is doing more work. If you engineered your system correctly, the amount of processing work done by the back-end only increases moderately. If you didn’t follow best practices, the number of calls between server and database could increase and slow down performance.

It’s tricky, often requiring customized engineering effort, to handle coaching, authorization, versioning, and pagination effectively.

Getting GraphQL right is hard.

A successful example of a large-scale application using GraphQL in production is GitHub’s switch from API to GraphQL. They maintain a GraphQL explorer for their API, through which one could explore production data in real-time.  

An earlier version of this blog was published on Medium by the author.

Recent Publications
How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way
How to remix Amazon’s Working Backwards with Google’s Venture’s User Journey: The Dr. Strange Way
June 14, 2022
How we built a big data platform for a futuristic AgriTech product
How we built a big data platform for a futuristic AgriTech product
June 3, 2022
Zemoso Labs starts operations in Waterloo, Canada
Zemoso Labs starts operations in Waterloo, Canada
May 25, 2022
Deconstructing Elon Musk’s dog ate my homework answer for Twitter: More validation will be asked of startups
Deconstructing Elon Musk’s dog ate my homework answer for Twitter: More validation will be asked of startups
May 20, 2022
Real Talk: Lessons learned and evolved from 3M and Post-it®’s adoption of Crazy 8 methodology
Real Talk: Lessons learned and evolved from 3M and Post-it®’s adoption of Crazy 8 methodology
April 10, 2022
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 1
Why Realm trumps SQLite as database of choice for complex mobile apps — Part 1
February 7, 2022
Understanding dynamic multi-column search with JPA Criteria for product development
Understanding dynamic multi-column search with JPA Criteria for product development
January 2, 2022
Product engineering zeitgeist: Implement OOPs in React JS using atomic design
Product engineering zeitgeist: Implement OOPs in React JS using atomic design
July 8, 2021
Honorable mention at O’Reilly’s Architectural Katas event
Honorable mention at O’Reilly’s Architectural Katas event
May 17, 2021
Product dev with testable spring boot applications, from day one
Product dev with testable spring boot applications, from day one
May 4, 2021
When not to @Autowire in Spring or Spring Boot applications
When not to @Autowire in Spring or Spring Boot applications
May 1, 2021
Efficiently handle data and integrations in Spring Boot
Efficiently handle data and integrations in Spring Boot
January 24, 2021
Unlock the power of atomic design in React and React Native using a theming library — Part 1
Unlock the power of atomic design in React and React Native using a theming library — Part 1
November 2, 2020
Our favorite CI/CD DevOps Practice: Simplify with GitHub Actions
Our favorite CI/CD DevOps Practice: Simplify with GitHub Actions
October 25, 2020
Kubernetes — What is it, what problems does it solve, and how does it compare with alternatives?
Kubernetes — What is it, what problems does it solve, and how does it compare with alternatives?
June 21, 2019
Orchestrating backend services for product development with AWS Step Functions
Orchestrating backend services for product development with AWS Step Functions
April 1, 2019
How To Decide When to Use Amazon Working Backwards, Business Model Canvas and Lean Canvas
How To Decide When to Use Amazon Working Backwards, Business Model Canvas and Lean Canvas
November 30, 2018
How to validate your Innovation: Mastering Experiment Design
How to validate your Innovation: Mastering Experiment Design
November 22, 2018
Working Backwards: Amazon's Culture of Innovation: My notes
Working Backwards: Amazon's Culture of Innovation: My notes
November 19, 2018
Product developer POV: Caveats when building with Spark
Product developer POV: Caveats when building with Spark
November 5, 2018
ZEMOSO ENGINEERING STUDIO
April 30, 2019
12 min read

GraphQL — Why is it essential for agile product development?

For most digital products, communication between the Client and Server is one of the most vital parts. Over the years, there have been many attempts to make this more efficient and streamlined. 

RPC, an old school approach

One of the first approaches for handling client-server communication is Remote Procedure Calls (RPC). Here, the client calls a function/procedure on the server through the request.

 Example of a RPC to-do list application
Example To-do list application

As an example, consider a to-do list application. A user using this application can create/view “lists.” A list can contain a set of “Items.” Users can add/delete “items” in the “list,” and move an “item” from one “list” to another.

Challenges with RPC

There are a few challenges with this approach,

● Exposing the functions and implementation details to the client introduces tight coupling between client and server code. Every time a change is to be made on the server, the corresponding client code should be updated as well.

● Another issue is discoverability. There's no direct way for the client to know that a given Application Programming Interface (API) exists. Usually, supporting external documentation outlining such details will have to be shared.

● For each specific requirement, one could end up adding a new function on server-side code, which will return the exact data required by the client. But such a practice will soon result in something called “function explosion”. Where there are numerous unnecessary functions in the server side code, each of which is useful to one specific request.

REST

In 2000,  REpresentational State Transfer (REST) was introduced.

The main idea in REST is that any information that needs to be exposed to the client will be abstracted as a resource. The client can view/update the state of these resources through requests to the server.

To refer to an interface as RESTful six constraints must be satisfied.

1.    Client-server

2.    Uniform interface

3.    Stateless

4.    Cacheable

5.    Layered System

6.    Code on demand

Example to-do app: REST approach

Let us design the same to-do application now with REST. First, we have to identify the objects in our domain and represent them as resources. Here list and item are good choices for resources to be exposed through API. The set of API calls mentioned above will transform as follows.

●    GET /lists

●    GET /lists/42/items

●    POST /lists/42/items

●    DELETE /items/24

GET /lists fetches all the lists. GET/lists/42/items fetches all the items in a list with id 42 and so on. There's no tight coupling, and the client will be able to navigate through the APIs using hyperlinks provided.  

Problems with REST

● Large payloads: A RESTful API will always respond with a resource. All the fields in a resource may or may not be relevant to the client all the time. Thus, the client will end up processing a large payload.

● Increased round trips between client and server: A client could end up making multiple requests to the server to fetch relevant data. This will increase the number of requests to the server and could affect the performance of both the server and client.

On a powerful device connected to a high-speed network, both of these problems are hardly noticeable.

But,  when a user on a mobile device tries to get something from the application, the above problems will throttle performance and make the application unusable.

This was the exact problem engineers at Facebook faced in 2012, and the project they undertook to solve the problem evolved into  “GraphQL”.

What is GraphQL?

To quote the official documentation

GraphQLis a query language for APIs and a runtime for fulfilling those queries with your 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 is an alternative approach to client-server communication. It is a specification, which outlines the structure and behavior of request and response that are to be exchanged between a client and a server.

GraphQL doesn't mandate a particular programming language or storage system for application servers that implement it.  There are numerous implementations of GraphQL in various languages/frameworks.

It facilitates efficient and effective communication between client and server.

In the initial stages, GraphQL’s main goal was to tackle the problems of large payloads and multiple round trips. It solves this problem by giving clients the power to ask for exactly what they need and nothing more.

Example to-do app: GraphQL approach

Let us consider the to-do app example, again. We have the same requirement: client wants to know the “name” field of the first item in the second list in application. With GraphQL, the contents of the request and response exchanged through API calls could look as follows:

Contents of GraphQL request sent from the client
Contents of GraphQLrequest sent from the client
 Contents of GraphQL response from server
Contents of GraphQLresponse from server

The client sent only one request to the server, and received one response, which contained the exact required field. Value for the field is “Write” as we can see in the above example.

Since the client can ask what it wants and get exactly what it needs in a single round-trip both the problems of processing large payloads and multiple round trips are avoided here.

We used a query type request; these are used for reading the data. The query accepts an optional argument; if optional arguments are present, the server could use them to narrow the search and filter the data. Here, we're interested in the second list only. Thus we pass positions:[1] when communicating our requirements to the server.

Inside the list, we only mentioned items; this will inform the server that we are only interested in that field and other fields aren't required. Items field accepts an optional parameter position, which is an array. We're interested only in the first item; thus we pass positions[0].Inside items, we mention name; this cues the server that it should include only the name field in the response.

Here is a comparison graphic to summarize our discussion:

Comparison with RPC, REST and GraphQL

When should one use GraphQL? 

GraphQL is a robust approach and a very good choice for certain scenarios. Unfortunately, there's no one-size-fits all answer, but we've seen GraphQL work in most scenarios.

To determine the best approach for your product development, you must ascertain which guarantees are essential and intolerable constraints on your API design.

GraphQL is an especially good choice when designing a mobile-first user experience. It helps erode response delays with limited computing power and slower networks, making for a better user experience.

GraphQL simplifies querying with complex schemas, and improves developer productivity.

Caveats with GraphQL

Like any other solution, GraphQL has a few constraints.

Using GraphQL you can request and receive only the relevant data; this is achieved by moving the responsibility of “getting the relevant data” from the client onto the server.

Instead of the client parsing a large payload, the server now parses a relatively complex request. Depending on the request, the server will hit the database (multiple times if needed) and aggregate all the relevant data that was requested. The server then prepares the response as per the request and sends it back to the client.

Although the client here's doing less work, the back-end is doing more work. If you engineered your system correctly, the amount of processing work done by the back-end only increases moderately. If you didn’t follow best practices, the number of calls between server and database could increase and slow down performance.

It’s tricky, often requiring customized engineering effort, to handle coaching, authorization, versioning, and pagination effectively.

Getting GraphQL right is hard.

A successful example of a large-scale application using GraphQL in production is GitHub’s switch from API to GraphQL. They maintain a GraphQL explorer for their API, through which one could explore production data in real-time.  

An earlier version of this blog was published on Medium by the author.

Recent Publications

ZEMOSO ENGINEERING STUDIO

How we built a big data platform for a futuristic AgriTech product

June 3, 2022
8 min read
ZEMOSO NEWS

Zemoso Labs starts operations in Waterloo, Canada

May 25, 2022
5 min read
ZEMOSO ENGINEERING STUDIO

Honorable mention at O’Reilly’s Architectural Katas event

May 17, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Product dev with testable spring boot applications, from day one

May 4, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

When not to @Autowire in Spring or Spring Boot applications

May 1, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Efficiently handle data and integrations in Spring Boot

January 24, 2021
5 min read
ZEMOSO ENGINEERING STUDIO

Our favorite CI/CD DevOps Practice: Simplify with GitHub Actions

October 25, 2020
5 min read
ZEMOSO PRODUCT STUDIO

How to validate your Innovation: Mastering Experiment Design

November 22, 2018
8 min read
ZEMOSO PRODUCT STUDIO

Working Backwards: Amazon's Culture of Innovation: My notes

November 19, 2018
8 min read
ZEMOSO ENGINEERING STUDIO

Product developer POV: Caveats when building with Spark

November 5, 2018
2 min read

Want more best practices?

Access thought-leadership and best practice content across
the product development lifecycle

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

© 2021 Zemoso Technologies
Privacy Policy

Terms of Use
LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies

© 2021 Zemoso Technologies
Privacy Policy

LinkedIn Page - Zemoso TechnologiesFacebook Page - Zemoso TechnologiesTwitter Account - Zemoso Technologies
June 22, 2022