It can be tough to pick the technologies that will be included in the tech stack of your next project. In many cases — and especially when it comes to choosing between GraphQL and RESTful APIs — it’s all about choosing the next best API design architecture.
There are four significant ways to build APIs: SOAP, GRPC, REST, and GraphQL. We often narrow our minds to REST and GraphQL whenever we want to build APIs. This is because REST changed the traditional ways of building APIs with SOAP and GRPC.
GraphQL is widely tagged as a better REST because it represents a better way of building APIs. Many developers believe that GraphQL will replace REST. Many more have already discovered that GraphQL helps solve some common challenges developers face while building REST APIs.
These two methods of building APIs are entirely different. In practice, these technologies work by sending an HTTP request and receiving the result. They both have their pros and cons, and in this article, we will extensively discuss these two great technologies that have changed the way we develop and scale APIs.
Before we dive into the details, though, let’s first explore the meaning of GraphQL and RESTful APIs.
What Is GraphQL?
GraphQL is an API query language as well as a runtime for answering those queries with existing data. It also comes equipped with powerful tools for handling even the most complex of queries.
GraphQL’s central feature is its ability to request and receive only the specific data requested — nothing more. This makes it much simpler to scale your APIs along with your app.
The most exciting part of GraphQL is its ability to provide you with all the data in one endpoint.
The above diagram is a typical representation of GraphQL architecture. Clients make requests from different devices, and GraphQL handles their requests and returns only their requested data. This neatly solves the problem of over-fetching and under-fetching in RESTful APIs.
In the above sample, we show a GraphQL playground and how you can query for data with a single endpoint. At the top is the API endpoint, by the left is the query that requests names of continents, and lastly, on the right, we respond to the query we requested.
GraphQL was created by Facebook for the primary purpose of solving their mobile app developer’s experience while working with REST APIs. Since its first open-source version was released in 2015, GraphQL has experienced tremendous growth due to the adoption of the technology by big players in the tech business.
Companies Using GraphQL
Below is a list of just some of the companies and applications using GraphQL actively on their servers.
Facebook created GraphQL, and they’ve used it in production to power their mobile apps since 2012. The multi-billion-dollar social network company open-sourced the GraphQL spec in 2015, making it accessible across many environments and to teams of all sizes.
GitHub
GitHub also announces the use of GraphQL by providing a GraphQL API for creating integrations, retrieving data, and automating your workflows using the GitHub GraphQL API. The GitHub GraphQL API offers more precise and flexible queries than the GitHub REST API.
Pinterest is also an early adopter of GraphQL. The photo-sharing giant has publicly discussed their early exploration of GraphQL and how they use the GraphQL technology that powers their billion-dollar company.
Many other billion-dollar companies such as Intuit, Shopify, Coursera, and Airbnb power their applications with GraphQL. And this wide-reaching preference to REST is only continuing to grow.
What Is RESTful API?
REST stands for “Representational State Transfer,” which is a software architectural style for distributed hypermedia systems. It defines principles and constraints for exchanging resources between the server and the clients.
If these principles are followed in an API, that API’s application is referred to as “RESTful.” The WordPress REST API is a prime example of this.
Below are some of the principles and constraints an API must satisfy to be referred to as a Restful API:
- Client-Server Decouple: The clients (frontend) and the server (backend) are completely separate and can only communicate through the endpoints.
- Uniform Interface: Data seen in the interface is identical across all devices.
- Statelessness: The server does not remember if the current request is being made for the first time or not. Each time a request is made, it needs to include all information necessary to process it from scratch.
- Cacheability: Caching and session storage is permitted, but they must be configured to allow end-users to opt out of data caching.
- Layered System Architecture: APIs must be designed so neither the client nor the server can tell whether they’re communicating directly or through an intermediary.
The diagram below is of basic REST architecture. It shows how requests and responses are typically handled.
GraphQL vs REST: What’s the Difference?
The main difference is how they communicate with the server. GraphQL is a newer technology that uses a single endpoint to respond to queries, while REST uses a set of endpoints that respond to specific HTTP requests. GraphQL is generally considered more efficient and flexible than REST.
Benefits of GraphQL
Below are a few benefits of using GraphQL, which illustrate why it’s more than sufficient for building the next billion-dollar app.
Fetching Data Through a Single API Endpoint
The top advantage of GraphQL is its ability to access any or all data points through a single API endpoint.
One of the most common problems with RESTful APIs is having too many endpoints to access information. In GraphQL, you only have a single endpoint, so you don’t need to send multiple requests to retrieve different information about an object.
The diagram below depicts a clear example of retrieving resources using RESTful API and GraphQL. You can see that there’s only one endpoint to access the resource in the GraphQL server, while multiple API endpoints are needed to access different resources in the RESTful API.
No Over-fetching or Under-fetching
The issue of over or under-fetching is a known problem with RESTful APIs. This is when clients download data by hitting endpoints that return fixed data structures, or else they retrieve either more or less than what they expected.
Over-fetching results in the request receiving — or “fetching” — more data than what’s required by a given request. Imagine you’re fetching all the users in a table with the intention of displaying their usernames on your homepage. In that case, over-fetching will return all the data on each user, including (but not only) the name.
Under-fetching is comparatively rare, but it does happen when the specific endpoint fails to provide all the requested information. The client will need to make additional requests to access the other information as needed.
GraphQL efficiently solves the problem of over-fetching or under-fetching by grabbing the exact resource that the client requested without any extra details.
Better Handling of Complex Systems and Microservices
GraphQL can unify and hide the complexity of integrated multiple systems.
For instance, say we want to migrate from a monolithic backend application to a microservice architecture. The GraphQL API helps to handle communication between various microservices by merging them into one GraphQL schema.
Once these schemas are defined, both the frontend and the backend can communicate separately without any further changes, since the frontend knows that the data in the schema is always going to be in sync across the system.
Fast and Secure
The problem of over-fetching can result in higher bandwidth consumption for clients, which may, in time, cause lagging in your application. Using RESTful API design patterns is more time-consuming to sort out the information needed from an enormous payload.
Because of GraphQL’s ability to avoid over fetching and under fetching, the server returns a secure, easy-to-read, and predictable shape which makes your API requests and responses faster.
Benefits of REST
Despite GraphQL’s growing popularity, REST is still one of the most popular API standards. Let’s take a peek at why.
- Learning Curve: RESTful APIs are the easiest to learn and understand. This is its primary advantage over other APIs.
- Serialization: REST comes with a flexible approach and formats for serializing data in JSON.
- Caching: REST API can manage a high load with the help of an HTTP proxy server and cache.
- Complex Request: REST APIs have a separate endpoint for different requests, and that helps make the complex request more manageable than in other APIs
- Clean and Simple: REST APIs are elegant, simple, and clean. They are straightforward to explore.
- Standard HTTP Procedures: REST uses standard HTTP procedure call-outs to retrieve data and make requests.
- Client/Server: This means that its business logic is decoupled from the presentation. So you can change one without impacting the other.
- REST Is Stateless: All the messages exchanged between client and server have all the context needed to know what to do with the message.
Drawbacks of GraphQL
Now that we’ve discussed the pros of GraphQL vs REST, let’s explore some of GraphQL’s drawbacks:
- Difficult Learning Curve: GraphQL is not as easy to learn as REST. The most challenging part of building a GraphQL API is designing the schema. This takes a lot of time and domain knowledge.
- File Uploading: GraphQL does not have a native file upload feature. This can be worked around using Base64 encoding, but the cost of encoding and decoding this way can be time-consuming and expensive.
- Web Caching: Caching helps reduce frequent traffic to the server, which speeds up the requests and the response process by keeping frequently accessed information close to the server. GraphQL does not support or rely on HTTP caching methods, depending instead upon the caching mechanisms of the Apollo or Relay clients.
- Unsuited for Small Applications: GraphQL may not be the best API architecture for building a small application. If your app does not require the more flexible queries offered by GraphQL, REST is the way to go.
- Complex Query Issue: GraphQL’s ability to give a client exactly what it wants can also lead to query propagation issues. If a client submits too many nested queries, it can lead to the wrong queries being sent, which can be very time-consuming for the server. It’s better to utilize REST with custom endpoints to meet such requests.
Drawbacks of REST
Now, let’s turn our attention to some of REST’s drawbacks:
- Multiple Round Trips: The biggest problem with REST APIs is the nature of numerous endpoints. This means for the client to get all the resources for a complete application, it needs to do innumerable round trips to get the data.
- Over-fetching and Under-fetching: The problem of over-fetching and under-fetching is a major drawback in RESTful APIS. It can cause lagging in responses due to fetching large unwanted payloads.
- Hierarchy: Since REST APIs are built on URI referencing resources, they are a poor fit for resources that are not naturally organized or accessed in a simple hierarchy.
Why Use GraphQL Instead of REST?
Next, we will discuss why you might want to consider GraphQL for your future API development instead of RESTful API.
Strongly Typed Schema
GraphQL uses a strong type system to define the capabilities of the API. In GraphQL, schema definition language (SDL) is used to define the parameters surrounding how the client accesses the server’s data. All APIs exposed to the client are written down in SDL, solving the data inconsistency problem seen in RESTful APIs.
No Over-Fetching or Under-Fetching
The issue of over- or under-fetching is a known problem with RESTful APIs in which clients get back either more or less information than they requested. GraphQL solves this problem by providing a medium for the client to specify the information needed, then returning exactly — and only — that specific information.
Multiple Endpoints
One of the biggest problems of RESTful APIs is having too many endpoints to access information.
Let’s assume you want to access a particular user via their ID number. You’d be presented with an endpoint like /users/1. But if you want to access that user’s photos, you’ll have to send a request to another endpoint, such as /users/1/photos.
In GraphQL, you have a single endpoint, and you don’t need to send multiple requests to retrieve different information about the user.
GraphQL vs REST Showdown
Lastly, we are going to explore the major difference between GraphQL and RESTful APIs. After that, we’ll discuss some of the features of a good API design and compare how each technology handles them.
Performance
There is no doubt that GraphQL performs faster than RESTful APIs because of its ability to provide a single endpoint to access all your resources. RESTful APIs use multiple endpoints, which could result in network latency.
Query Complexity
Since endpoints are not separated into multiple endpoints, GraphQL queries can become increasingly complex over time. RESTful API endpoints, on the other hand, are separated, which restricts RESTful APIs to simple queries.
Popularity and Community Support
GraphQL is a growing API architectural pattern and query language. Although it’s still young, its adoption rate and resource pool are growing rapidly, and resources already abound for those interested in learning it for themselves.
REST, on the other hand, already boasts vast community support and continues to be used by companies of all kinds, ranging from those building small microservices to those creating complex social apps and beyond.
At present, the popularity contest between GraphQL vs REST is a draw. Both technologies continue to be widely used and well supported by the development community.
Learning Curve
The learning curve for GraphQL is steep. It requires good domain knowledge of API development and general software engineering. A complete beginner will have a tough time understanding GraphQL well enough to build a complex application.
Conversely, REST is very easy to get started with and requires less domain knowledge out of the gate. RESTful API is well integrated into most major programming languages and popular frameworks, which makes learning it very easy.
Summary
GraphQL is a new technology that follows in the tracks of RESTful API architectural patterns, just as REST was introduced to solve problems with SOAP API patterns.
GraphQL offers you faster responses, a single API endpoint for all your queries, and a strict schema for consistent data access. These reasons are what’s made multi-billion-dollar companies start switching to GraphQL, even in the early stage. However, despite its limitations, GraphQL’s progenitor REST continues to maintain a strong presence on the stage.
In this guide, we’ve explored everything you need to know about GraphQL and RESTful APIs, including the benefits and drawbacks of each technology, in order to help you confidently decide which one you prefer. We’ve also discussed the known problems with RESTful APIs — such as over-fetching, under-fetching, and multiple endpoints — and how GraphQL attempts to solve those problems and boost your app’s performance.
You’ve now got enough insight to choose whether GraphQL vs REST is appropriate for your next project. Let us know in the comments section what you’ll be building with your chosen winner!
I am a Software Engineer and Content Creator who is geared toward building high-performing and innovative products following best practices and industry standards. I also love writing about it at Masteringbackend.com. Follow me on Twitter, LinkedIn, and About Me
Leave a Reply