APIs were developed to simplify the flow of data and information across multiple systems. As APIs have matured, different architectures have evolved for solving unique data needs and challenges. One of the architectures currently increasing in adoption is GraphQL. What does this mean? What should it be used for? How does it compare? Let's start breaking it down.
GraphQL is a type of API that was created as a result of social networks. Specifically, it was created by Facebook to control its news feed in native mobile applications. The challenge they experienced with REST APIs is that it is difficult to get additional information about the data point on demand, such as viewing a list of friends liking a story or comments on a post.
GraphQL is a query language that allows developers to have flexible query requests, calling specific data and returning it from several sources in one call. In the Facebook example, this allows developers to create dynamic queries fetching personalized parameters for pulling data from users’ news feeds. In addition, these APIs are designed to be versionless, allowing continuous deployment changes without requiring redeployment of the entire API. GraphQLs also typically have a single endpoint and can batch multiple queries into a single request, reducing the number of network round trips and improving efficiency.
GraphQL APIs take a unique approach to querying data and while it can be easier to call data, there are important benefits and challenges to consider. Below is a list of some pros and cons for GraphQL APIs.
|
Pros |
Cons |
|
Querying the relational graph architecture is highly flexible and allows fields or types to be changed without breaking existing clients |
Learning curve required for developers not familiar with the query language |
|
Strongly typed APIs makes it easy for developers to discover and document available data |
May not solve for under-fetching or excessive nesting as it does for over-fetching |
|
Single endpoint makes it more efficient for clients to request data in a single request |
If poorly designed, can lead to performance and security issues |
|
Batching multiple queries helps reduce the number of network requests and improves efficiency |
Caching and schema maintenance can be more challenging |
There is a lot to consider when selecting which API is appropriate for a particular data request. Going back to the Facebook example, social media platforms can use GraphQL to query information on who liked the post, and who commented on the post in a single request. While created for this very specific use case, GraphQL has expanded to support many different scenarios. It is best for real-time updates, such as chat apps and live feeds, or aggregating data from multiple sources and dealing with complex data relationships. Additional examples are listed below.
Applications for devices where bandwidth usage is important
Scenarios where nested data needs to be fetched in a single cell
Data retrieval from multiple sources, such as logging services, backends, analytics tools, etc.
Abstraction on an existing APIs
While there are many use cases for GraphQL, there are scenarios where GraphQL might not be the appropriate API of choice. Below are scenarios where REST, gRPC, or SOAP architectures may be more appropriate.
Straightforward CRUD (create, read, update, delete)
Applications that rely heavily on caching entire responses
Situations where performance and low overhead are critical
Legacy system calls that are not easily adaptable to GraphQL
Scenarios where strict contracts and documents are required
Resource-oriented APIs
The nature of GraphQL APIs set it apart from other more commonly leveraged APIs, such as REST. Some best practices for management include creating consistent naming within the GraphQL schema to make data easier to identify, avoiding hard-coded parameters that could expose sensitive data, and creating flexibility for future modifications and extensions to the schema. From a security perspective, GraphQL APIs are susceptible to standard API attacks, such as XSS, injection, DDoS attacks and broken authorization. Additionally, GraphQL’s unique built-in documentation may allow attackers to find injection or mutation opportunities even more efficiently than other options. The flexibility of the queries could be abused by attackers, including being utilized to bulk query and perform a variety of different attacks in a single pass. Some best practices for improving security posture include limiting exposure of API documentation publicly, maintaining limits on how long a query can run, and placing authorization closer to the objects or data.
However, the question of whether a net new solution is required for managing and securing these APIs from the rest is still being debated. Many holistic API management and API security solutions today do support GraphQL APIs and claim their approaches can handle the nuances of this API architecture. On the other hand, there are solutions evolving solely designed to manage and secure GraphQL APIs, including Apollo for API Management and Inigo and Escape for GraphQL Security. While these solutions claim GraphQL requires a different set of solutions, our Trace3 Innovation team is continuing to track this market and update our Pillars of API Security as new information surfaces.
If you are interested in learning more about API Security, please don’t hesitate to reach out to us at innovation@trace3.com