Are OData and GraphQL Comparable?

I'm writing this post mainly because I'm tired of reading whether OData is better or worse than GraphQL, and so on, when in reality, both solutions SHOULD NOT be compared, as they solve two different problems. 

In this post I won’t go into the detailed characteristics of each of these technologies; for that, we will see individual posts, one about GraphQL for sure and possibly one about OData as well. This post is to show where OData shines as well as where GraphQL does. 

1 - What is OData?

Simply put, OData is a library that you add to your API and it allows you to make REST calls to request only the information you need. 

Imagine you have an app, and in the web version you display user details like type, name, surname, id, address, etc. But in the mobile version, you only display the name and surname. Technically, for the mobile version, you could use the same request as for the web version. However, if you have thousands or hundreds of thousands of requests, the extra data you return can turn into a significant monetary cost, especially because that extra data is discarded.

That's where OData comes in: instead of having to create two different endpoints, you can use OData, which automatically creates such endpoints and lets you simply indicate the properties you need from a given object or objects. 

Both requests go to "the same endpoint". Moreover, it allows you to return objects that are linked inside the main object or to make queries on other objects at the "root" level. 

If, in this example, we didn't have OData, most likely we would have to make one call for the user data, another for the bank data, and so on. 

Of course, this also implies that we return much more information than we need. As always, if it's just a few calls, this doesn't hurt, but if it's hundreds or thousands, it does. 

By the way, OData allows you to define all CRUD operations (Create, Read, Update, Delete), as well as filter, sort, and paginate data.

Before finishing with OData: when OData is not used, you usually have a backend endpoint that covers all the frontend needs; as we have seen, with OData that's not necessary, OData by itself is very powerful and covers that need.

2 - What is GraphQL? 

Just like before, I won't go into detail, just a first overview. GraphQL is a query language that lets you define the data structure on the client side. In other words, a client requests the data it needs and thus we save on data transfer. 

As you can see in the picture, architecturally, it's the same as OData. So, why do I say they're not comparable? 

3 - OData VS GraphQL, Which one to choose? 

Given what we just saw, aren't we actually comparing them? 

Well, the reality is that they are not comparable, or at least they shouldn't be, mainly for a couple of key reasons.

OData is a library that goes into your application individually and automatically maps the database to REST endpoints.

But, what happens in the world of microservices? What if the information is very divided? Going back to the previous case, what if we have the banking information in a separate microservice? 

The answer is clear: we would have to make two different calls, which could potentially delay the display of the data to the user, depending of course on the complexity of these calls.

So, with this information, we realize that OData works very well in an environment where we have a monolith or a modular monolith, but not so well in microservices environments. 

Now let's move on to GraphQL. Like OData, GraphQL is a library that goes into your API individually, BUT it has a major difference with OData: GraphQL creates what's called a schema, which is read by a supergraph and combined with other schemas to create a group of subgraphs, making it so that, from the frontend perspective, there is only a single request, since we’re really calling the supergraph.

It's the supergraph (or gateway) that is responsible for finding out where the information can be retrieved from, querying it, and assembling it to return it to the user. 

Of course, for everything to work correctly, the schema configuration must be set up properly (types/objects, etc.), as it's used to detect when an object is split across multiple microservices. 

3.1 - When to use OData or GraphQL?

Finally, my opinion after working with both (with OData, only a PoC) is that GraphQL is very powerful and cool, but it’s used way too much in cases where it isn’t needed at all. 

Whole architectures that have 1-to-1 communication with the frontend and the APIs are just adding an extra layer of complexity. If this is your case, you DO NOT need GraphQL. If you have well designed microservices and the requests are good, GraphQL can be the best discovery for your application.

And OData can give you access to the whole database via a REST API with just a couple of lines of code. Depending on the state of your application, this can be very powerful. It also has more options than GraphQL, such as filtering, sorting, etc. If you want to filter or sort with GraphQL you have to do it manually in code. 

As you can see, both options may seem like alternatives at first glance, but they’re not, as they solve two completely different scenarios.