What is Data Virtualization? Understanding the Concept and its Advantages
Reading Time: 4 minutes

When you need to write code to access data, it is hard to beat the flexibility of SQL. SQL allows you to ask for exactly the data you need, for example to combine data from multiple tables and target precisely the lines and columns that are useful to you, in one single SELECT statement. However, when you need to integrate back-end applications with front-end applications, a REST API is the natural choice. REST has become the de facto standard for web and mobile applications, largely because of its interoperability and robustness. 

What do you choose when you need to integrate back-end data with front-end applications? REST APIs tend to be rigid and static: exactly the opposite of SQL’s flexibility. Until recently, developers just made do with REST, but with GraphQL, you no longer have to. 

Why REST Alone Is Not Enough

A REST API is a set of HTTP endpoints that allow applications to access resources or perform actions via HTTP requests. The input and output of each endpoint is strictly defined. For example, consider a typical REST API endpoint to request information about a customer. It may require a customer ID as input, and return a long list of JSON fields including address, date of birth, contact details, and loyalty card information. A separate REST API endpoint may be required to request information about customer’s orders, such as the purchase amount and delivery dates.

In this example, consider which data is easily accessible and which is not. It is easy to look up a customer by ID, but challenging to find a customer with a given loyalty card number or last name. The items in a single order may be easy to access, but finding all the customers who ordered similar items would require a huge number of calls to the API and may be impractical to implement for performance reasons. What’s more, even simple requirements may involve retrieving a lot of useless information: If a developer only requires an item’s shipping data and cost, the API they use will still return a product name, description, brand, and category.   

In short, data access via traditional REST APIs is susceptible to under-fetching and over-fetching.  Under-fetching is when multiple API calls must be made to retrieve all the necessary data. Over-fetching is when a single API call returns unneeded data. Both can negatively affect application performance and maintainability. 

See It in Action

In this short video, I will show you just how easy it is to build a GraphQL API using the Denodo Platform. Hopefully this will make you want to learn more and try it out for yourself! 

GraphQL to the Rescue

GraphQL enables developers to specify the exact data they need and receive exactly that: no more, no less. Queries are sent via POST calls to an API endpoint, and the content specifies precisely which fields are required. It is easy to navigate relationships between objects, example to access a customer and all their orders in one request, as shown in the example below:

{ customer (lastName : “Lewis”) {
    customerKey,
    firstName,
    lastName,
    customerOrders
        {orderNumber, orderDate, orderTotal}

    }}

Sending this request to a GraphQL endpoint requests specific information about all customers with the last name “Lewis”, including a detailed list of their orders. 

A response would look something like this:

 {
    “data”: {
        “customer”: [
            {
                “customer_key”: 81296,
                “first_name”: “Carl”,
                “last_name”: “Lewis”,
                “customer_orders”: [
                    {
                        “order_number”: 41315,
                        “order_date”: “2017-05-11 07:00:00”,
                        “order_total_net_paid”: 17612.36
                    },
                    {
                        “order_number”: 19375,
                        “order_date”: “2015-09-04 07:00:00”,
                        “order_total_net_paid”: 53553.46
                    }
                ]
            },

            {
                “customer_key”: 58592,
                “first_name”: “Lana”,
                “last_name”: “Lewis”,
                “customer_orders”: [
                    {
                        “order_number”: 34139,
                        “order_date”: “2017-06-16 07:00:00”,
                        “order_total_net_paid”: 48500.06
                    }

]
            }
        ]
    }

It is interesting to notice a few things in that example: 

  1. GraphQL enables us to search via a flexible field – in this case, last name – instead of using whichever one is determined by the API endpoint.
  2. GraphQL enables us to query two entities together – in this case, customers and orders – without making multiple calls to the API.
  3. GraphQL enables us to choose which fields appear in the response, so that only useful data is returned.

In short, one call to a GraphQL API can give you precisely the data you need, without under-fetching or over-fetching. 

Implementing GraphQL APIs Simply and Efficiently with the Denodo Platform

The concept of GraphQL is simple, but as with many things data, the implementation can be complex. A back-end GraphQL server needs to be able to interpret the query and translate it into a performant strategy for obtaining the necessary data from the underlying data storage systems. This can be challenging to implement as well as costly to maintain and adapt. The implementation will likely be quite specific to the underlying storage technology as well, which could lead to limited options to adopt new technologies in the future. 

This is where the Denodo Platform can be an important accelerator for GraphQL projects. The Denodo Platform enables you to deploy any view on any storage system as a GraphQL object. GraphQL queries are automatically optimized by the Denodo Platform using exactly the same advanced performance techniques that are applied to Denodo Platform queries via JDBC or ODBC. If you are planning a migration project, the Denodo Platform enables you to easily switch the storage behind a GraphQL object without changing the API, so that consuming applications are not impacted. 

Emily Sergent
Latest posts by Emily Sergent (see all)