Should I Choose a GraphQL or REST for my API?

Have you ever searched for videos from your favorite band on YouTube? All you have to do is type in the name, tap the magnifying glass and off you go! Now you have a list of videos and live shows you can enjoy into the wee hours. An API (Application Programming Interface) is working in the background to help you find even the most obscure videos from your favorite band, provided they’re available online. The API is an intermediary that links two applications so they can interact and exchange data efficiently for the benefit of the end-user.

Naturally, there’s a lot going on behind the surface that the user never sees. But if you’re in charge of deciding how to create and implement an API that will provide the biggest benefit for your customers, then you need to know a little more about what’s happening behind the curtain. For instance, will you use a GraphQL or a REST API? Here at Spark Equation, our IT experts can dive deep into the details with you to choose and implement the right behind-the-curtain elements for creative, focused API solutions that make your apps incredibly smooth, helpful, and easy to use. So, let’s talk about the benefits and drawbacks of REST and GraphQL.

What REST & GraphQL Have in Common

Both REST and GraphQL are industry-standard interfaces that can make your API easier for the end-user. They both:

• Hold strong, developer-friendly standards that are easy to access and understand.
• Are interpreted as a product instead of a code.
• Enable target users to come up to speed quickly with provided documentation and set expectations that come with specific versions, which helps developers accurately predict when maintenance or updates may be needed
• Come standardized so the discipline for governance and security is much stronger.
• Enable the interpretation of an API as a product; in other words, there is a specific software development lifecycle (SDLC).

Beyond these commonalities, REST and GraphQL have a lot of differences too. Understanding these differences can help you decide which direction is the best one for your clientele.

REST API

REST has been around for decades, determining just how APIs will look and act. It’s a stable, time-proven platform. The acronym stands for “Representational State Transfer”, and it contains a set of rules developers adhere to as they churn out APIs. In REST APIs, the type of data requested depends heavily on the query method. For example, one rule dictates that you can call up a resource (piece of data) if you link to a certain URL. The URL is the request, the data you receive back is the response. Just like everything in life, REST has pros and cons you need to be aware of:

Pros of REST

• REST relies on caching, built-in HTTP specification. The semantics of getting the data you need are well defined and can be easily followed. GET requests...

• Can be cached

• Can stay in the browser history

• Can be bookmarked

• Are idempotentREST can also be easily monitored with leverage from HTTP status code.

• REST can also be easily monitored with leverage from the HTTP status code.

Cons of REST

• They provide only a single-resource fetch.

• A request must be chained to the client before forming the answer.

• Implementation is needed.

• With REST APIs, users need to manually implement parsing and returning logic to specify the information they require.

• JSON schemas can be used to show schemas and strong types

• Query languages such as OData can be used

• Although all of the above is possible to do, it is much harder than using GraphQL

To bring it all home, REST is a time-tested, useful API with impressive multitasking abilities, but it requires professional upgrades from time to time to get the most out of it. Developers like its security and framework independence also. It has also been useful for integrating with clients on Java, JS, and .NET. So, from a systematic viewpoint, many developers prefer it for its high productivity and narrow queries. With that in mind, a REST system can operate with less dependence on its other parts, which means that glitches in other areas have a smaller impact on the whole system than there otherwise would be.

On the other hand, it’s important to keep in mind that REST is very strongly tied together with HTTP, so it has become less useful for working within web services that have higher, more advanced requirements.

GraphQL API

Ever since Facebook launched GraphQL in 2015, its popularity has skyrocketed. Everyone from startup companies to established market-leading enterprises have adopted it as their go-to API for a plethora of web services.

But what is GraphQL exactly? It’s a type of syntax that specifies how to request data. It can be used to upload data from a server to the client, and it provides the user three main benefits: empowering the client to specify the exact data needed, making it easier to collect data from multiple sources, and using a type system that clearly describes the data. This makes it possible for a user to use one request to pull up the necessary data, instead of putting together several different REST requests to gather the same information. In short, it can do more complex queries - faster.

Just like REST, GraphQL has its pros and cons, which we will break down here:

Pros of GraphQL

• Strong data typing, contact-driven by nature.

• Supports Boolean, String, Int, Float, ID, Scalar, and many others, all of which are specified in the Schema.

• It uses Schema Definition Language (SDL), which turns out to be quite profitable and useful. Specifically:

• Fewer errors appear.

• Much better-validated integrated development environment (IDE).

• Simplifies the process by providing auto-completion.

• It can fetch information in whatever volume necessary.

• Due to strong typing, nothing less or more appears when data is fetched.

• It’s practically made for serverless work. With serverless functions, users don’t have to worry about subscriptions, and it works very well with a single endpoint. Nowadays, entire servers work like this, which provides all the benefits of “serverlessness” with very few (if any) of the disadvantages.

Cons of GraphQL

• GraphQL can be difficult to monitor.

• Unlike REST, which leverages HTTP, GraphQL is not as easy to monitor and control.

• It can send back frustrating error messages that don’t provide much in the way of assistance, and look like this: {"errors":[{"message": "Something gone wrong"}]}.  Yikes!

• Caching can be difficult.

• While using REST, it’s usually clear how cacheable each endpoint is.

• GraphQL is based on a graph system (surprise!), and the endpoints are connected to enable users to query which episode they are on, which makes it more difficult to set the caching policy.

• It creates the probability of less-well performing queries.

• Complex queries demand several endpoints to retrieve data for specific queries, which leaves more room for error when something goes wrong.

• While GraphQL can process big queries, it may take longer, and without proper precision, it can actually knock out the server.

• Tougher testing makes it trickier to anticipate and remedy all of the possible problems ahead of time.

• Clients are forced to use GraphQL for testing instead of standard HTTP operations, such as Get and POST. This is why GraphQL cannot easily be tested in a web browser, or with command-line utilities.

• It reduces the availability of shared-nothing architecture.

Let’s talk for a moment about GraphQL implementation. One of our developers recounted how he used the GraphQL API on a small project for just four people. This solution was easy to work with between different clients, specifically the browser and mobile app. It took the back-end development team some time to get used to this API and optimize it for large queries. But the result was a streamlined deployment of the new functionality that was up and running quite rapidly.

Furthermore, unlike the REST API, the GraphQL API didn’t require more documentation, which saved considerable time and allowed a faster implementation. In other cases, documentation had to be set aside because of the high workload. So, our developers found that GraphQL works particularly well for projects that have a high likelihood of functional change. On the other hand, our developers would not recommend GraphQL for use in backend-buildable projects.

The Bottom Line

The Spark Equation development team takes extra steps to understand the needs of each specific project. Because every project is unique, we analyze each aspect so that we can find the most efficient, simple, and elegant solution that will make your app work perfectly. Your situation may be best served with REST. A different situation may call for GraphQL. In order to come up with your best solution, we follow a specific thought process; a decision tree, if you will, as outlined in the diagram below:

1. As you can see, the first step is to understand the amount of hierarchical data that the served application will need to fetch in just one query call.
2. Next, we need to understand how critical bandwidth usage is going to be in the finished product.

If the answer to both these questions is “Yes”, then the GraphQL API is your best bet.

For apps where bandwidth isn’t as important, we ask a third question: will the app need to retrieve data from several APIs or not? If the answer is, “No,” then REST is the best way to go.

If you have an app that needs an API to really connect with clients and customers, it’s important to consult with experts about your specific project needs so that you can make the right key decisions for quick, agile development. Although APIs like REST and GraphQL are used for similar reasons, the mechanisms behind requesting and retrieving the necessary data differ significantly. Using the right one can mean the difference between finding that awesome music video you’ve been searching for, or getting back a list of singing cat videos. Choosing one of these APIs, or another API altogether largely rests on what you want to accomplish. Making the right choices along the development path can boost your business into brilliant new realms of customer happiness.  

Send us a message about an API situation you are trying to puzzle out, and let us put our multidimensional thinking caps on to come up with a solution that will help you grow.

‍