DEV Community: Ujwal Kumar

The What and The How of Indexes in Databases

Ujwal Kumar — Sat, 30 Mar 2024 06:11:07 +0000

What is an Index?

An index is a data structure associated with a table that speeds up the retrieval of rows. By creating an index on a column or a set of columns, the database engine can locate relevant rows more efficiently. This is particularly useful for large tables or queries that frequently filter or sort data.

Types of Indexes:

On a broad level, there are two categories of indexes:

Clustered Index: A clustered index is a type of index that defines the physical order of the rows in a table based on a column. A clustered index directly sorts and stores the table's data based on the indexed column(s). By default, in many database systems, the primary key constraint creates a clustered index on the primary key column(s). This ensures that the primary key uniquely identifies each row in the table and also determines the physical order of the rows. In most database systems, each table can have only one clustered index, as the physical order of the rows can only be based on one criterion only.
Non-Clustered Index: A non-clustered index is a type of index that creates a separate data structure (generally B+ trees) to store index keys and pointers to the corresponding rows. A non-clustered index does not affect the physical order of the rows on disk. In contrast to clustered indexes, which are limited to one per table, a table can have multiple non-clustered indexes. While non-clustered indexes enhance query performance, they also require additional storage space to store the index keys and pointers.

Critical Considerations

Although indexes are a powerful tool to optimize query performance on tables which are read-heavy and are updated less frequently, there are a few things that should be kept in mind while creating indexes on a table. Here are some key considerations:

Creating indexes on columns that are frequently used in WHERE, JOIN, ORDER BY and GROUP BY clauses can improve the performance of your queries.
Too many indexes can lead to overhead in terms of storage and maintenance. The number of columns in the index definition will directly affect the performance of insert, update and delete operations.
We should choose as few columns as possible in tables with intensive data updates for the index definition.
We should define the clustered index in as few columns as possible. Ideally, our clustered index should be defined in a unique column and not contain a null value.
The more repetitive data we have in the column where we define the index, the lower our index performance will be.
For queries that involve multiple columns in the WHERE clause or JOIN conditions, consider creating composite indexes (indexes on multiple columns). Composite indexes can improve query performance by allowing the database to quickly filter or match rows based on combinations of column values.
We should be careful about the order of the columns in composite indexes. As a rule of thumb, column with most distinct values should come first in the composite index.

By keeping these considerations in mind, you can create indexes that effectively improve query performance, optimize resource utilization and enhance overall database efficiency.

How does Index help to improve query performance?

To understand how do indexes help to improve the query performance, let us take a look at a example table.

Table Name: Users

Field Name	Storage (in bytes)
Id	4
Name	8
Age	4
City	8
Country	8

Each record in this table will take 4+8+4+8+8 = 32 bytes of storage. Let us assume this table contains 100 records. Data is stored in different blocks in the disk. When we want to read data from the table, the database engine reads the data from the disk in the form of blocks. Each block has some size of data that it can hold. Let us assume the block can store 128 bytes of data, then each block will contain 4 records. Let us also assume that reading each block from disk takes around 1 second. If we want to fetch the user by age, in worst case, we will have to fetch 25 blocks to find the relevant record(s) which will take around 25 seconds (in real world databases the data read from the disk is less as lot of the databases use data structures like B+ trees, AVL trees etc. for performance optimization). If we have an index on the age column, then the index would be sorted on the indexed column and for representational purpose we can consider it to look something like below.

Age	Address on Disk
11	4
12	2
13	5
16	1
19	11

We will have 100 records with two columns for the index. One of them is age and other is the address of the record on disk. Age takes 4 bytes and let us assume the address also takes 4 bytes. The total size for 100 records for this index would be 800 bytes. The number of blocks required to store the index would be 800/128 = 6.25 ~ 7 blocks. To fetch a single record from the database, the amount of blocks that would be needed to be read by the database engine will be 7 for the index plus 1 block for the data (assuming all records matching that age reside on the same block). On the basis of our assumption, this will take around 8 seconds. So total improvement factor for the query will be 25/8 = 3.125. As we can see, even in a small table there is significant improvement in the query. This improvement is even more visible when we have huge tables with lots of records.

Conclusion

Indexing is a very useful technique that helps in optimizing the search time in database queries. The main purpose of indexing is to provide better performance for data retrieval. We have to be extremely smart while applying indexes. In-depth knowledge of the queries that run on the tables is an extremely important prerequisite. Sometimes an index may have negative impacts like slower inserts/updates/deletes and large disk storage that need to be taken care of before creating index on a table.

Overview of Azure Kubernetes Services

Ujwal Kumar — Wed, 27 Sep 2023 16:36:14 +0000

What is Azure Kubernetes Service (AKS)?

Azure Kubernetes Service is Microsoft Azure’s managed Kubernetes solution that lets you run and manage containerized applications in the cloud. As a hosted Kubernetes service, Azure handles critical tasks like health monitoring and maintenance.

Since Kubernetes masters are managed by Azure, you only manage and maintain the agent nodes. Azure Kubernetes Service offers provisioning, scaling and upgrades of resources as per requirement or demand without any downtime in the Kubernetes cluster.

Azure Kubernetes Service Architecture

When a user creates an AKS cluster, a control plane is automatically created and configured. The control plane is a managed Azure resource the user cannot access directly. The control plane contains resources that provide interaction for management tools, maintain the state and configuration of the Kubernetes cluster, schedule and specify which nodes run the workload and oversee smaller actions, such as replicating Kubernetes pods or handling node operations.

Azure Kubernetes Service deployments covers two resource groups. One group is the Kubernetes service resource, while the other is the node resource group. The node resource group contains all of the infrastructure resources associated with the cluster.

Advantages of Azure Kubernetes Service

Azure Kubernetes Service offers numerous features such as creating, managing, scaling and monitoring Azure Kubernetes Clusters. Following are some of the advantages of using Azure Kubernetes Services:

Smooth development experience

Azure Kubernetes Service reduces the debugging time while handling patching, auto-upgrades, self-healing and simplifies the container orchestration. It definitely saves a lot of time and developers will focus on developing their apps while remaining more productive.

Efficient utilization of resources

A fully managed Azure Kubernetes Service offers easy deployment and management of containerized applications with efficient resource utilization that elastically provisions additional resources without the headache of managing the Kubernetes infrastructure.

Quicker development and integration

Azure Kubernetes Service supports auto-upgrades, monitoring, and scaling and helps in minimizing the infrastructure maintenance that leads to comparatively faster development and integration.

Security and compliance

Cybersecurity is one of the most important aspects of modern applications and businesses. Azure Kubernetes Service integrates with Azure Active Directory (AD) and offers on-demand access to the users to greatly reduce threats and risks. AKS is also completely compliant with the standards and regulatory requirements such as System and Organization Controls (SOC), HIPAA, ISO, and PCI DSS.

Azure Kubernetes Service Features

Microsoft Azure offers Azure Kubernetes Service that simplifies managed Kubernetes cluster deployment in the public cloud environment and also manages health and monitoring of managed Kubernetes service. Customers can create AKS clusters using the Azure portal or Azure CLI and can manage the agent nodes.

A template-based deployment using Terraform can also be chosen to deploy the AKS cluster that manages the auto-configuration of master and worker nodes of the Kubernetes cluster. Some additional features such as advanced networking, monitoring and Azure AD integration can also be configured. Let’s take a look into the features that Azure Kubernetes Service offers:

Open-source environment: Microsoft has inducted number of employees in last couple of years to make Kubernetes easier for the businesses and developers to use and participate in open-source projects and became the third giant contributor to make Kubernetes more business-oriented, cloud-native, and accessible by bringing the best practices and advanced learning with diverse customers and users to the Kubernetes community.
Nodes and clusters: In AKS, apps and supporting services are run on Kubernetes nodes and the AKS cluster is a combination of one or more than one node. These AKS nodes are run on Azure Virtual Machines. Nodes that are configured with the same configuration are grouped together and are called node pool. Nodes in the Kubernetes cluster are scaled-up and scaled-down according to the resources that are required in the cluster. So, nodes, clusters and node pools are the most prominent components of your Azure Kubernetes environment.
Role-based access control: AKS easily integrates with Azure Active Directory (AD) to provide role-based access, security and monitoring of Kubernetes architecture on the basis of identity and group membership.
Integration of development tools: Another important feature of AKS is the development tools such as Helm and Draft are seamlessly integrated with AKS where Azure Dev Spaces can provide a quicker and iterative Kubernetes development experience to the developers. Containers can be run and debugged directly in Azure Kubernetes environment with less stress on the configuration.
Ability to run any workload: You can orchestrate any type of workload running in the AKS environment. You can move .NET apps to Windows Server containers, modernize Java apps in Linux containers or run microservices in Azure Kubernetes Service.
Simplified User Experience: AKS removes your implementation, installation, maintenance and security complexities in Azure cloud architecture. It also reduces substantial costs where no per-cluster charges are being imposed on you.

Azure Kubernetes Service Use Cases

AKS usage is typically limited to container-based application deployment and management, but there are numerous use cases for the service within that scope.

You could use AKS to automate and streamline the migration of applications into containers. First, it could move the application into a container, register the container with ACR and then use AKS to launch the container into a preconfigured environment. Similarly, AKS can deploy, scale and manage diverse groups of containers, which helps with the launch and operation of microservices-based applications.
AKS usage can complement agile software development paradigms, such as continuous integration/continuous delivery and DevOps. For example, a developer could place a new container build into a repository, such as GitHub, move those builds into ACR, and then rely on AKS to launch the workload into operational containers.
Data streaming can be made easier with AKS as well. The tool can be used to process real-time data streams in order to perform a quick analysis.
Other uses for AKS involve the internet of things (IoT). The service, for instance, could help ensure adequate compute resources to process data from thousands, or even millions, of discrete IoT devices. Similarly, AKS can help ensure adequate compute for big data tasks, such as model training in machine learning environments.

Summary

Azure Kubernetes Service is a powerful service for running containers in the cloud. AKS is certainly an ideal platform for developers to develop their modern applications using Kubernetes on the Azure architecture where Azure Container Instances are the pretty right choice to deploy containers on the public cloud. Best of all, you only pay for the VMs and other resources consumed, not for Azure Kubernetes Service itself, so it’s easy to try out.

Overview of Redux Concepts

Ujwal Kumar — Sat, 15 Apr 2023 16:44:38 +0000

Redux is one of the most popular state management libraries. It is simply a store that contains the state of the variables in your app. Redux creates a streamlined process to interact with the store so that components will not just update or read the store randomly. It integrates well with other javascript libraries like React, Vue or Angular. While creating complex applications, managing the state among several components is challenging. Redux aims at solving this exact problem.

Redux Terms and Concepts

Let us have a look at some of the terms and concepts you'll need to know to use Redux.

State Management

Let's start by looking at a small React counter component. It tracks a number in component state, and increments the number when a button is clicked:

function Counter() {
  // State: a counter value
  const [counter, setCounter] = useState(0)
  // Action: code that causes an update to the state when something happens
  const increment = () => {
    setCounter(prevCounter => prevCounter + 1)
  }
  // View: the UI definition
  return (
    <div>
      Value: {counter} <button onClick {increment}>Increment</button>
    </div>
  )
}

The app contains the following parts:

The state, the source of truth that drives our app.
The view, a representation of the UI based on the current state.
The actions, the events that occur in the app based on user input, and trigger updates in the state

State describes the condition of the app at a specific point in time. The UI is rendered based on that state.
When something happens (such as a user clicking a button), the state is updated based on what occurred.The UI re-renders based on the new state.

However, it can be tricky when we have multiple components that need to share and use the same state. Sometimes this can be solved by "lifting state up" to parent components, but even that is not the most clean solution in all scenarios.

Another way to solve this is to extract the shared state from the components, and put it into a centralised location outside the component tree. Any component can access the state or trigger actions, no matter where they are in the tree. This is the basic idea behind Redux.

Immutability

JavaScript objects and arrays are all mutable by default. In order to update values immutably, your code must make copies of existing objects/arrays, and then modify the copies. We can do this by hand using JavaScript's array/object spread operators, as well as array methods that return new copies of the array instead of mutating the original array.

Terminology

Below are some of the important react terms that you need to be familiar with.

Actions

An action is a plain JavaScript object that has a type field. You can think of an action as an event that describes something that happened in the application.

The type field should be a string that gives this action a descriptive name, like "tasks". We usually write that type string like "domain/eventName", where the first part is the feature or category that this action belongs to, and the second part is the specific thing that happened.

An action object can have other fields with additional information about what happened. By convention, we put that information in a field called payload.

A typical action object might look like this:

const addTaskAction = {
  type: 'tasks/tasksAdded',
  payload: 'Read a book'
}

Action Creators

An action creator is a function that creates and returns an action object. We typically use these so we don't have to write the action object by hand every time:

const addTask = task => {
  return {
    type: 'tasks/tasksAdded',
    payload: task
  }
}

Reducers

A reducer is a function that receives the current state and an action object, decides how to update the state if necessary, and returns the new state: (state, action) => newState.

Reducers must always follow some specific rules:

They should only calculate the new state value based on the state and action arguments.
They are not allowed to modify the existing state. Instead, they must make immutable updates, by copying the existing state and making changes to the copied values.
They must not do any asynchronous logic, calculate random values, or cause other "side effects".

Here's a small example of a reducer, showing the steps that each reducer should follow:

const initialState = { value: 0 }
function counterReducer(state = initialState, action) {
  // Check to see if the reducer cares about this action
  if (action.type === 'tasks/addTasks') {
    // If so, make a copy of `state`
    return {
      ...state,
      // and update the copy with the new value
      value: state.value + 1
    }
  }
  // otherwise return the existing state unchanged
  return state
}

Store

The current Redux application state lives in an object called the store. The store is created by passing in a reducer, and has a method called getState that returns the current state value.

import { configureStore } from '@reduxjs/toolkit'
const store = configureStore({ reducer: counterReducer })
console.log(store.getState())
// {value: 0}

Dispatch

The Redux store has a method called dispatch. The only way to update the state is to call store.dispatch() and pass in an action object. The store will run its reducer function and save the new state value inside, and we can call getState() to retrieve the updated value:

store.dispatch({ type: 'counter/increment' })
console.log(store.getState())
// {value: 1}

You can think of dispatching actions as "triggering an event" in the application. Something happened, and we want the store to know about it. Reducers act like event listeners, and when they hear an action they are interested in, they update the state in response.

We typically call action creators to dispatch the right action.

const increment = () => {
  return {
    type: 'counter/increment'
  }
}
store.dispatch(increment())
console.log(store.getState())
// {value: 2}

Selectors

Selectors are functions that extract specific pieces of information from a store state value. As an application grows bigger, this can help avoid repeating logic.

const selectCounterValue = state => state.value
const currentValue = selectCounterValue(store.getState())
console.log(currentValue)
// 2

Redux Application Data Flow

How Redux works?

Redux has a centralised store to store all the states of the applications that are easily accessible by all the app components. Each component does not have to pass the props around within the component tree to access those states, as displayed below.

To trigger the updation of the state, a user must start interacting with the view. The view will dispatch a required action if you want to update a state. The action will reach the reducers and update the state in the store as per the action. A view is subscribed to the store that will listen about the change in any state. Changes are notified using the subscription method that will reflect in the UI.

Summary

We have discussed the major features of Redux and why Redux is beneficial to your app. While Redux has its benefits, that does not mean you should go about adding Redux in all of your apps. Your application might still work well without Redux.

One major benefit of Redux is that it allows you to manage your app's state in a single place and keep changes in your app more predictable and traceable.

useMemo vs useCallback

Ujwal Kumar — Sun, 12 Feb 2023 15:42:11 +0000

useMemo and useCallback are two of the react hooks that help us in optimizing the performance of our application whenever components are re-rendered. They can be very useful in case you want to prevent some expensive computations from happening in your application (eg. an api call to the server that does some expensive calculations).

In this article, we will take a look on how to use these two hooks, what kind of problem do they solve and the difference between the two.

useMemo

The useMemo hook is used to return a memoized value. Memoization is a popular concept that refers to returning or reusing a cached value instead of computing it every time given the parameters used to calculate the value have not changed from the previous computation.

The official syntax of useMemo is useMemo(expensiveFunction, [dependencies]). From the syntax we can see that useMemo takes in two arguments. First argument is the expensive function call that we want to avoid while re-render of our component. This function should be pure, cannot take any arguments and the result of this function could be of any type. The second argument is a list of dependencies.

The function that is passed to useMemo is called during first time render of our component. Subsequent re-runs would depend on the list of dependencies that have been passed to the useMemo hook. If the dependencies have not changed, the old value is reused otherwise new value will be calculated. If no dependencies are passed, the expensive function will be called on each render.

Example

import { useMemo } from 'react';

function UserList({ users, profile }) {
  const activeUsers = useMemo(() => filterActiveUsers(users, profile), [users]);
}

In the above example, we have received users as a prop inside our component. Let us say that filterActiveUsers is a very expensive method call that takes in too long time to give a result. If we want to stop the expensive method to re run everytime our UserList component is rendered, we can use useMemo to stop this function from running the next time given that the dependencies (users and profile in this case) do not change.

useCallback

The useCallback is used to return a memoized version of a callback. It's typical use case is when a child component expects a callback from a parent component and we want to prevent unnecessary re-renders of a child component.

The syntax of useCallback is useCallback(function, [dependencies]). As we can see, it is very similar to useMemo as in they both take a function as a first argument and takes in a list of dependencies as the second argument. The function definition that we pass in as the first parameter is cached and it can also take in some arguments which can be used for our business logic.

React returns (not call) the function that is passed as an argument to the useCallback hook on first render. The next time when this component re-renders, react checks the dependency list and will only compute the definition if the list of dependencies have changed from the last render.

Example

import { useCallback } from 'react';

export default function Cart({ productId, userId, orderDetails }) {
  const handleSubmit = useCallback((orderDetails) => {
    post('/product/' + productId + '/buy', {
      userId,
      orderDetails,
    });
  }, [productId, userId, orderDetails]);

return (
    <div>
      <Shipping onSubmit={handleSubmit} />
    </div>
  );

In the above example, useCallback returns a function that can take in orderDetails as an argument. The function definition is stored inside handleSubmit. This function can in turn be passed to the child component (Shipping). The child component can then use this function. The function definition is cached and will only be recomputed in case the dependencies change on subsequent re-renders.

Be careful! Do not overuse these methods!

While these two hooks provide a solution to a real problem, we should be careful that we don't use them at the wrong place or overuse them.

For instance, there is no need to memoize a function that’s doing some basic calculation. We should only use useMemo when we know that a function will be very expensive either in terms of time of computation or in terms of the usage of resources. The results of useMemo gets stored in memory and can stay their for long time which in the long run may harm the performance of your application.

With useCallback as well there could be similar problems that we could create if we start caching simple function definitions. As these functions will stay in memory for longer periods of time and will not get garbage collected which in turn will again harm the performance of your application.

Key differences between useMemo and useCallback

useMemo is used to store the return value of a function in memory whereas useCallback is used to store the definition of a function.
The function passed to useMemo cannot take any arguments whereas the function in the useCallback hook can take parameters.
The function passed to useMemo is called on component render and it's returned value is cached in memory whereas useCallback just returns the function you passed to it but does not call it on component render.

GraphQL vs REST

Ujwal Kumar — Sat, 20 Aug 2022 07:37:00 +0000

Introduction to GraphQL vs REST

REST is one of the most common way of developing API(also known as Application Programming Interface). People have been using REST for a long time but since GraphQL became open source in 2015, there have been constant debates on whether GraphQL is superior to REST API.

As everything, REST API and GraphQL both have pros and cons, which need to be considered while designing your solutions. In this article I would like to explain what is REST API and what is GraphQL. I will go through the major difference between them and try to explain the pros and cons of both them so people can make a good choice based on their requirements.

What is REST API?

REST API was presented in 2000 by Roy Fielding. REST stands for Representational State Transfer. REST is a set of architectural constraints, not a protocol or a standard. API developers can develop REST in different ways. When a request is made via a REST API, it transfers a representation of the state of the resource to the requestor. This information can be delivered in one of the several formats: JSON (Javascript Object Notation), HTML, XML or even plain text. JSON is the most popular file format to use because it's language-independent as well as readable by both humans and machines. REST API communicates using HTTP requests with GET, POST, PUT, PATCH and DELETE methods

In the above image you can see that client is sending the request using one of the REST API methods, next server responds with XML, HTML or JSON data depending on the request.

There are certain constraints that should be followed be while designing a REST API.

1. Uniform Interface - It states that there should be a uniform way of interacting with the server irrespective of the client. There are four guideline principles of this constraint:

Resource Based - Individual resource are identified in a request.
Manipulation of Resources through Representation - Client has representation of resource and it should contain enough information to modify or delete the resource on the server.
Self-Descriptive Messages - Each message includes enough information to describe how to process the message.
Hypermedia as the engine of application state(HATEOAS) - The term hypermedia refers to any content that contains links to other forms of media such as images, movies, and text. REST API response can include links so that client can discover other resources easily by following the links.

2. Stateless - All communications between the client and the server needs to be stateless. The server does not store any information from the previous requests. Client needs to provide all the information in each request so that the server can process it as an individual request.

3. Cacheable - Every response should include whether the response is cacheable. Client will return the data from its cache for any subsequent request and there would be no need to send the request again to the server.

4. Client-server - This constraint means that client applications and server applications must be able to evolve separately without any dependency on each other.

5. Layered system - There can be lot of layers of intermediate servers between client and the end server. Intermediary servers may improve system availability by enabling load-balancing and by providing shared caches.

6. Code on demand - It is an optional feature. According to this, servers can also provide executable code to the client. The examples of code on demand may include the compiled components such as client-side scripts such as JavaScript.

REST request structure

Any REST request includes four essential parts: an HTTP method, an endpoint, headers and a body.

1. HTTP Method - An HTTP method describes what is to be done with a resource. Get, Post, Put, Patch and Delete are the common REST methods.

2. Endpoint - An endpoint contains a Uniform Resource Identifier (URI) indicating where and how to find the resource on the Internet.

3. Headers - These mainly store information relevant to both the client and server. Mainly, headers provide authentication data such as an auth token and the information about the response format.

4. Body - Body is used to convey additional information to the server. For instance, it may be a piece of data you want to send in a post request to be added on the server.

What is GraphQL?

GraphQL was developed by Facebook, which first began using it for mobile applications in 2012. The GraphQL specification was open sourced in 2015. GraphQL is a query language for APIs. GraphQL makes it possible to access many sources in a single request, reducing the number of network calls and bandwidth requirements.

Types and Resolvers in GraphQL

A GraphQL service is created by defining types and fields on those types, then providing functions(resolvers) for each field on each type. For example, a GraphQL service to fetch student details could have the type as below:

type Query {
  student(rollNo: String!): Student
}
type Student {
  name: String
  rollNo: String
}

The resolver for the above query could be something like below

const resolvers = {
  Query: {
    student(parent, args, context, info) {
      return db.students.get(args.rollNo); // fetches student data from database based on rollNo
    }
  }
}

Queries, Mutations, and Subscriptions in GraphQL

Queries, mutations and subscriptions form the core features of GraphQL and help us to leverage GraphQL to build better APIs.

Queries

Queries are data requests made by the client from the server. GraphQL only discloses single endpoint, allowing the client to determine what information it actually requires.

{
  Students {
    rollNo
  }
}

The field ‘Students’ in the above mentioned query is known as the root field. This query will result in the rollNo of all the students.

{
  “Students”: [
    {“rollNo”: “A1”},
    {“rollNo”: “A2”},
    {“rollNo”: “A3”}
  ]
}

Mutations

Mutations are used to create, update or delete data. The structure is almost similar to queries except for the fact that you need to include the word "mutation" in the beginning. For instance:

mutation {
  createStudent (name : “Daryl”, rollNo: ”A1”){
    name
    rollNo
  }
}

Subscriptions

Subscriptions are a way to create and maintain real time connection to the server. Basically, a client subscribes to an event in the server, and whenever that event is called, the server will send the corresponding data to the client.

Let’s say we have an app where we need to fetch students in real time and want to subscribe to the event of creation of a new student. Below subscription could be used for this type of requirement:

subscription {
  newStudent {
    name
    rollNo
  }
}

Comparison of GraphQL and REST

Usability

GraphQL allows you to send a request to your API to get the exact result without requiring anything extra from in the response. Thus, GraphQL queries return highly predictable results providing excellent usability.

With REST the behaviour of the API wildly varies depending on the URI and HTTP method chosen, making it difficult for consumers to know what to expect with a new endpoint.

Data Fetching

It is quite a common scenario to fetch more data than you need in REST than in GraphQL as each endpoint in REST specification includes a specific data format. Similarly, with REST it’s also common to under fetch the dataset, forcing clients to make additional requests to get relevant data. The case is quite different when it comes to GraphQL. Since it’s a query language and supports declarative data fetching, the users can only get what they actually need from the server.

Caching

Caching is an integral part of the HTTP specification that REST APIs can use. On the other hand, GraphQL has no caching system, thus leaving the users with implementing their own caching system.

Monitoring and Error Reporting

When using REST we can monitor the API usage based on status messages. On GraphQL you don't have that, because it always return 200 OK status response. A typical GraphQL error looks like this:

HTTP 200 OK
{
  errors: [
    {
      message: 'Something when wrong'
    }
  ]
}

Performance

Performance is one area where GraphQL has an advantage over REST. As mentioned in the data fetching section, due to the problem of under-fetching and over-fetching, REST API tends to perform poorly as compared to GraphQL

Security

REST provides several ways to enforce the security on your APIs. For instance, in methods like HTTP authentication, sensitive data is sent in HTTP headers, through JSON Web Tokens. GraphQL also provides some measures to ensure your APIs’ security, but they are not as mature as those of REST.

So which should I choose?

This really depends on your use case. Neither REST nor GraphQL are better than one another. They simply work differently.

If you are concerned about retrieving exactly the data you require and want a more declarative way to consume your API then probably GraphQL would be the better choice. Also it saves bandwidth by solving the problem of under-fetching and over-fetching.

REST provides an easier caching and monitoring system. REST has easier ways to implement authorisation and security in comparison to GraphQL. So if the above points are your primary concern, then go ahead with REST.