What is GraphQL and what is REST API?
GraphQL is a query language that describes how clients request information through an application programming interface (API). It provides a syntax developers can use to request specific data and return that data from multiple sources. The client defines the desired data structure and the server returns the exact same data structure.
GraphQL provides read, monitor, and mutate features that allow data to be updated in real time. The goal of GraphQL is to give developers a comprehensive view of the data stored in the API, the ability to receive only relevant data, and an easier way to extend and adjust the data schema of an API over time.
GraphQL Vs. REST API: 4 key differences
In GraphQL APIs, when a client makes a request to the API, it gets the exact result needed without any unnecessary content. GraphQL queries return predictable results, greatly improving usability. In addition, GraphQL does not allow versioning of APIs, which simplifies client interaction.
In REST APIs, results returned for a request depend on the HTTP and URI methods used. This can cause API consumers to call endpoints without knowing what to expect. In addition, REST does not have standardized guidelines for version control. This means that each provider is free to implement their own approach, making integration more difficult.
GraphQL has clear performance advantages. GraphQL uses a flexible query style that lets the client get what it needs with a single API request. After the client defines the structure of the required information, the server returns exactly that structure. This prevents over-fetching and under-fetching, which is common with RESTful services.
REST APIs have inherently strict data structures designed to return specific data for each request, which often results in sending of unnecessary data and multiple iterations before the client receives the data it needs. This typically increases the time it takes for the server to return the requested information.
While GraphQL is faster than REST in many cases, there are some use cases in which REST APIs perform better – for example, when clients make predictable, monotonous calls that are cached for performance.
GraphQL is able to authenticate and authorize client requests, but is a new technology, so it is not yet fully mature when it comes to security. Additionally, due to its dynamic nature, additional safeguards should be used to prevent denial of service (DoS). With no safeguards in place, clients can make requests that consume a huge amount of resources.
REST APIs support authentication and use Transport Layer Security (TLS) to encrypt communications. While the REST architecture does not have explicit security features, there is a great deal of experience in the industry on how to build RESTful APIs in a secure manner.
GraphQL allows clients to simply send a query with their data requirements to the server, and the server responds with a JSON object.
REST APIs often require clients to access multiple endpoints to collect data. They use hierarchies of routes or endpoints, which can complicate data fetching.
GraphQL vs. REST: Which to choose?
Reasons to choose GraphQL
Compared to REST, GraphQL enables faster and less chatty communications, cutting down on requests by allowing clients to select only the fields they need to query. GraphQL unifies multiple systems behind a single API and hides their complexity, packaging the data into a standard response format. This is particularly useful for legacy infrastructure or third-party APIs that have grown over the years and are becoming difficult to maintain.
GraphQL also supports the transition from monolithic backend applications to microservices architectures. The GraphQL API helps to merge multiple microservices into a single GraphQL architecture, making inter-service communication easier. Each microservice defines its own GraphQL schema and has its own GraphQL endpoint, but the GraphQL API Gateway unifies these into one global schema.
Another advantage of GraphQL is that it keeps documentation synchronized with API changes. The GraphQL API is tightly coupled with code, so when a field, type, or query changes, the documentation automatically changes as well. This makes it much easier to evolve APIs over time while supporting collaboration between both internal and external developers.
Reasons to continue using REST
Despite the advancements introduced by GraphQL, there are several reasons to continue using REST APIs:
- Small apps – GraphQL is a good solution for large microservices systems, but for simple applications, REST will be easier to work with. Understanding and implementing GraphQL queries, even simple ones, can be time-consuming, while the resulting API is more flexible and easier to work with.
- Resource-driven applications – REST can also be a useful way to connect resource-driven applications that don’t require query flexibility.
- Supporting file upload – GraphQL doesn’t understand files, so the ability to upload files isn’t part of the spec. With REST you can POST or PUT whatever you want, including files.
Learning curve – most developers are familiar with REST APIs and will require training to become acquainted with GraphQL, especially when learning to define and work with schemas. In many use cases, REST is less architecturally complex.
Enabling GraphQL with Solo Gloo GraphQL
The Gloo GraphQL module embeds a GraphQL server natively into Gloo Mesh and Gloo Gateway, enabling federated GraphQL queries of your APIs using your service mesh and API gateways. No additional GraphQL servers required!
Combine the developer-friendly GraphQL query language for APIs with Istio’s ability to secure, manage, and observe application traffic across microservices. This eliminates the need for a distinct system of servers and schema libraries of parsers and resolvers for GraphQL; all of your policies and requests can be managed in Envoy Proxy filters. Leveraging the existing capabilities Solo.io provides via Envoy, you can scale from single, monolithic GraphQL APIs to a federated graph spanning multiple clusters.