‘When’ & ‘When Not’ to Use GraphQL
GraphQL is a potent query language for creating some astounding APIs – we all know that now. But, most people don’t know when GraphQL is the ideal option and when not. Today, we are going to figure out when and when not to rely upon GraphQL.
Source: GraphQL.org
What is GraphQL?
It is a phenomenal query language for your API and a server-side runtime for systematically implementing queries where a type system is used to define your data. GraphQL isn’t interlinked to a specific database or storage engine – your code and data merely back it.
GraphQL services are developed by defining types and fields on types and functions for each field. For instance, a GraphQL service that will show who is logged in as a user and its user name might appear like this:
type Query {
me: User
}
type User {
id: ID
name: String
}
Source: https://graphql.org/learn/
When to go for GraphQL?
Source: Slideshare
If you are planning to use GraphQL, in certain situations, you should use it without thinking twice such as:
When you are developing mobile apps
It would be best if you relied upon the strong shoulder of GraphQL when you are designing UI/UX rich applications for smartphones, smartwatches and IoT devices. GraphQL can help in loading content that the user actually needs and preserving the user experience under slow network speeds.
When you have to handle complex schema
GraphQL can assist in managing the complex schemas. If your application is based on numerous schemas that use multiple nested models and associations, you should go with GraphQL. REST is very weak in this section if you are likely to come in contact with complex queries. Being a query language, GraphQL can access the nested objects easily with a single API request and return structured data correctly tagged along with JSON.
When you want to hide backend complexities from client
GraphQL has two prominent features that make it a perfect situation for microservice orchestration. The first feature lets you abstract your RESTful API and create a unified and fully optimized public API for your microservices. The benefit of this feature is that you can handle future versions of your API smoothly. The second feature deals with the situation when you are creating a single GraphQL schema by stitching schemas together from multiple underlying GraphQL APIs. These both features help in hiding code complexities from the clients.
When you want better developing experience
The best scenario to use GraphQL is when you want to provide a better experience to your developers. With the descriptive language to handle complex queries, the capability to simplify the loading of state management and facility to manipulate types instead of tweaking with JSON data.
When your application receive data from multiple APIs
If you are developing a composite pattern application where your app retrieves data from multiple storage APIs, you should use GraphQL. For instance, when creating a dashboard that receives data from various sources such as logging services, backends for consumption stats and third-party analytics tools to capture end-user interactions. Using GraphQL, the proxy pattern on the client-side can be inserted to abstract an existing API. This way, each user can specify a response structure that revolved around their specific needs.
When to avoid GraphQL?
Source: Altexsoft
If you are looking forward to creating your API based on GraphQL, you should drop your idea in the following situations.
When you already have REST
GraphQL is an effective alternative to REST, so if you are acquainted with REST, why to settle for replacement? The primary feature of GraphQL is to send a query specified with the exact information that you need. But, this can be easily achieved using REST – from passing the name of the field to utilizing it in the URL. On top, there are a lot of JSON libraries available that can help you in implementing and supporting this specification.
When you want an easy way out
When you are aiming to develop a simple application with a couple of fields, GraphQL can over complicate your use by adding stuff like – types, queries, resolvers, mutators and other high order components. All these extra components are not at all feasible from the maintenance perspective. Thus, when you don’t want to stuck in the swirl of errors, don’t use GraphQL for simple applications.
When you want to use web cache
Implementing a web cache at the database level or the client level with in-memory cache implementation can be an easy task. A cache implementation at the HTTP level with a reverse proxy server that stores the content of a request – can reduce the amount of traffic that reaches a server. Since a REST offers numerous endpoints, which facilitates to configure web-cache to a URL easily.
When performance is your priority
GraphQL gives the power to execute queries to get the exact results. But, if a client sends a query for numerous fields and resources, you might face a performance issue. For complex queries, GraphQL must be designed very carefully, and you can’t just put it over the REST API or database. You have to define each endpoint and tune queries to retrieve specific data. All this designing and defining can affect the performance of the API.
When GraphQL schemas can cause a problem
By defining a schema, you can experience automate validation and introspect features. But, schemas are statics in the end; thus, the clients' response is going to depend on it. In GraphQL, you can expect more depth than you have specified, which means you have to compromise some of the GraphQL dynamic features. So, if your application doesn’t require a specified schema, you should avoid using GraphQL.
Parting thoughts
With adequate data on ‘when’ and ‘when not’ to use GraphQL, you can exploit the powerful query language in the right manner. GraphQL is an excellent alternative for REST, but not in all situations. Thus, evaluate your application and features that you want to incorporate in it before using the GraphQL. When GraphQL is used in the right scenario, the results can be great!