You've been building and using REST APIs for a while now, and recently you started hearing about GraphQL, a new fad in API technology. Some say it's good, others say it's not. I'm sure you're all wondering what all the excitement around GraphQL means and how it's different from the traditional approach.
The goal of this article is to highlight the main features of GraphQL and discuss the advantages and disadvantages of this particular API specification.
GraphQL is generally described as a front-end-oriented API technology because it allows front-end developers to request data in a much simpler way than before. Introduced by Facebook, the goal of this query language is to formulate customer applications trained on an instinctive and adjustable format, to describe their data needs as well as their interactions. The best part is that this language does not depend on any specific database management system and is actually supported by your current data and coding.
One of the fundamental problems with classic REST is the inability of the client to request a custom dataset. Additionally, running and controlling multiple endpoints is another challenge, as clients often need to request data from diverse endpoints.
When establishing a GraphQL server, it is important to have a single URL for completely obtaining and modifying data. Therefore, a user can request a set of data from a server by passing a query string, mentioning what they need.
GraphQL VS REST
What is GraphQL?
Taken directly from the GraphQL website: “GraphQL is a query language for APIs and a runtime engine for answering those queries with your existing data. GraphQL provides a complete, understandable description of your API data, gives customers the power to ask for exactly what they need and nothing more, makes it easy to evolve APIs over time, and enables powerful data analysis tools. development. »
A few things to clarify: GraphQL has nothing to do with databases themselves, it is simply a query language for querying a database. It is not an alternative to SQL, nor a completely new ORM. It's also not a replacement for REST, but rather an alternative, and you can use both in the same project!
Recap on REST
Taken directly from the RESTful website: “REST is the acronym for REpresentational State Transfer. It is an architectural style for distributed hypermedia systems, first introduced by Roy Fielding in 2000 in his famous dissertation. Like any other architectural style, REST also has its own 6 guiding constraints that must be satisfied if an interface is to be termed as RESTful. »
Another quick clarification: although many people compare the two, REST and HTTP are not the same. REST is the set of constraints that make a web service a true RESTful API. Arpit Jain puts it this way:
“HTTP is a contract, a communication protocol and REST is a concept. It is an architectural style that can use HTTP, FTP, or other communication protocols but is widely used with HTTP. REST involves a series of constraints on how the server and client should interact. HTTP is a communication protocol with a given mechanism for data transfer between server and client. It is most often used in the REST API simply because REST was inspired by the WWW (world wide web) which widely used HTTP before REST was defined, so it is easier to implement the style of REST API with HTTP. »
Comparison of architectures
With the explosion of mobile usage in the early 2010s, Facebook developed GraphQL to adapt to modern needs and simplify queries to improve performance on low-power devices and underperforming networks.
Let's take a moment to appreciate this simplicity by looking at REST and GraphQL architectures side by side:
Why GraphQL?
One of the main reasons for GraphQL is that a large number of databases used in modern web and mobile applications have a graph form. For example, a posted photo may have likes and comments, and those comments may have reactions, other comments, and user-created flags. This all forms a graph.
In addition to adapting to the data structure, GraphQL solves 3 major problems:
Less Extraction – There may be times when we need to extract data from multiple access points in order to retrieve all the data needed for a view. With REST, you have to make several requests, then process and use the retrieved data as needed. With GraphQL, we can make multiple trips to the server with a single query, retrieving all the data we need in one go.
Overfetching – Sometimes we only need a small portion of the data returned by a query. Retrieving a large amount of data to only use a tiny portion of it is simply inefficient and can slow down the application, and especially cause problems for people with bandwidth issues. With GraphQL, we can include only the parameters we want to query and avoid retrieving unnecessary data.
Slow front-end development – It's common that, given certain issues, we can create a new endpoint on the backend to simplify a fetch query for a specific view and avoid under- or over-fetching... but that takes work! With GraphQL, the client has the power to retrieve the data needed and nothing more. Nothing slows down, and no new endpoints are needed. It is very simple to add a new field to the query.
Recapitulation and synthesis
- Both REST and GraphQL can be retrieved by an HTTP request with a URL and return the request as JSON data.
- They both call functions on the server.
- They both have entry points, and they are both able to distinguish whether an API is intended to read or write data.
- GraphQL is a query language and toolset that uses HTTP to work on single endpoints for performance and flexibility through graph-organized data and schema-structured objects.
- With GraphQL, a single query can call multiple data points and respond only with the specific data requested, whereas with REST, each query calls only a single route processing function and returns all nested data.
- GraphQL doesn't include caching, error monitoring or reporting, or security against denial-of-service attacks, but it does offer some nice features like self-documentation and GraphQL Playground, where you can inspect your schema and even run queries and mutations to test your API.
If you're looking to develop a mobile app, consider using GraphQL because the bandwidth is more important - whereas if you're building an app that requires a robust API with caching and monitoring, it's probably better to use RESTful conventions. But then again… you can use both in the same project!
THANKS
