DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations

Trending

  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Effective Java Collection Framework: Best Practices and Tips
  • Writing a Vector Database in a Week in Rust
  • Comparing Cloud Hosting vs. Self Hosting

Trending

  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Effective Java Collection Framework: Best Practices and Tips
  • Writing a Vector Database in a Week in Rust
  • Comparing Cloud Hosting vs. Self Hosting
  1. DZone
  2. Software Design and Architecture
  3. Integration
  4. Introduction to GraphQL: A Query Language for APIs

Introduction to GraphQL: A Query Language for APIs

Learn about GraphQL, a query language designed to build client applications based on data requirements and interactions, and why you should use it to query data.

Shivangi Gupta user avatar by
Shivangi Gupta
·
Sep. 07, 17 · Tutorial
Like (8)
Save
Tweet
Share
6.31K Views

Join the DZone community and get the full member experience.

Join For Free

GraphQL is an API standard that provides a more efficient, powerful, and flexible alternative to REST. It was created by Facebook in 2012, was open-sourced in 2015, and is now maintained by a large community of companies and individuals from all over the world. GraphQL is a specification, meaning it's just a set of rules defined in a document.

GraphQL is a query language designed to build client applications by providing an intuitive and flexible syntax and system for describing their data requirements and interactions. It's been in production use in Facebook's native apps for several years.

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.

At its core, GraphQL enables declarative data fetching in which a client can specify exactly what data it needs from an API. Instead of multiple endpoints that return fixed data structures, a GraphQL server only exposes a single endpoint and responds with precisely the data, a client asked for.

GraphQL Is the Better Version of REST

Representational state transfer (REST) or RESTful web services is a way of providing interoperability between computer systems on the Internet. REST-compliant web services allow requesting systems to access and manipulate textual representations of web resources using a uniform and predefined set of stateless operations. Other forms of web service exist, which expose their own arbitrary sets of operations such as WSDL (Web Service Description Language) and SOAP (Simple Object Access Protocol).

Over the years, REST has become a standard for designing web APIs. It offers some great ideas, such as stateless servers and structured access to resources. REST itself is actually a strict specification of how a server has to expose the data to its clients. However, today, almost all APIs are labeled to be RESTful APIs even if they don't adhere to that specification.

However, REST APIs have shown to be too inflexible to keep up with the rapidly changing requirements of the clients that access them.

GraphQL was developed for more flexibility and efficiency in client server interactions, as it solves many of the shortcomings and inefficiencies that developers experience when interacting with REST APIs.

Data Fetching With REST vs. GraphQL

Let's consider a simple example scenario of a blogging application where the application needs to display the titles of the posts of a specific user. We will analyze how it will be handled by REST and GraphQL.

With REST, we have to gather data by accessing multiple endpoints and we have to make three requests to different endpoints to fetch the required data. There is also over-fetching since the endpoints return additional information that's not needed.

To fetch initial user data, we use access endpoint /users/:

To fetch all the posts of a user, we use access endpoint /users//posts:

To fetch followers per user, the endpoint is /users//followers:

With GraphQL, on the other hand, we simply send a single query to the GraphQL server that includes the concrete data requirements. The server then responds with a JSON object where these requirements are fulfilled. It works by sending a POST request to the server where in the body of the request, we include a query that describes all the data requirements of the client. In the below image, we can see that we are asking for a user with a particular ID and then we can specify all the data we want from that user — the name of the user, the titles of the posts by that user, and the names of the last three followers. When the server receives this query, it will process and resolve it to fetch exactly the data that is specified in the query and read it from the database. It will then package it up into a JSON object that it just returns to the client. We can see what the response will look like:

The root field in this JSON object is called data. That's what is specified in the official GraphQL specification, so exactly what we specified in the query is returned to the client.

Using GraphQL, the client can specify exactly the data it needs in a query. The structure of the server's response follows precisely the nested structure defined in the query.

So how is communication better in GraphQL?

REST API Architecture

First, the client has to make three requests for three kinds of data:

  1. For the user

  2. For his/her posts

  3. For his/her followers

Second, for every call, the server returns the unwanted data. When the client needs only the title of the user's posts, the server returns the content, ID, and comments along with the title of the posts. This creates more data transmission between client and server and slow communication.

GraphQL API Architecture

Only one server call will return all the required data from the server and the returned data will contain only the required information, hence less data transmission in just one call, and eventually, faster communication.

Now that we have a better understanding of the technical differences between GraphQL and REST, let's discuss a couple of high-level differences between them and see what other benefits GraphQL has compared to REST.

No More Over- and Underfetching

One of the most common problems with REST involves over-fetching and under-fetching. This happens because the only way for a client to download data is by hitting endpoints that return fixed data structures. It's very difficult to design the API in a way that it's able to provide clients with their exact data needs.

Overfetching means that a client downloads more information than is actually required in the app, for example, a screen that needs to display a list of users only with their names. In a REST API, this app would usually hit the endpoint /users and receive a JSON array with user data. This response, however, might contain more info about the users that are returned, i.e. their birthdays or addresses — information that is useless for the client because it only needs to display the users' names.

Underfetching means that a specific endpoint doesn't provide enough of the required information. The client will have to make additional requests to fetch everything it needs. This can escalate to a situation where a client needs to first download a list of elements but then needs to make one additional request per element to fetch the required data. This is underfetching and the n+1 request problem.

Benefits of a Schema and Type System

GraphQL uses a strong type system to define the capabilities of an API. All the types that are exposed in an API are written down in a schema using the GraphQL Schema Definition Language (SDL). This schema serves as the contract between the client and the server to define how a client can access the data.

Once the schema is defined, the teams working on the frontend and backend can do their work without further communication since they both are aware of the definite structure of the data that's sent over the network.

Frontend teams can easily test their applications by mocking the required data structures. Once the server is ready, the flip can be switched for the client apps to load the data from the actual API.

The aim of this blog was to introduce you to GraphQL and show you how it's better than REST. In the next blog, we will discuss the core concepts of GraphQL. So, stay tuned!



If you enjoyed this article and want to learn more about GraphQL, check out this collection of tutorials and articles on all things GraphQL.

GraphQL REST Web Protocols Database Data (computing) Query language

Published at DZone with permission of Shivangi Gupta. See the original article here.

Opinions expressed by DZone contributors are their own.

Trending

  • Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
  • Effective Java Collection Framework: Best Practices and Tips
  • Writing a Vector Database in a Week in Rust
  • Comparing Cloud Hosting vs. Self Hosting

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com

Let's be friends: