GraphQL vs. REST: Which Is the Best?

When building an app, choosing your API’s format is one of the most important decisions you can make.

An API connects each piece of your application. No matter how well the rest of the software is constructed, if the links are weak, the app will break.

In today’s web development landscape, the choice in API frameworks is between GraphQL vs. REST.

Will your app function best with the streamlined, modern approach of GraphQL? Or is the wisest choice the sturdy, tried-and-true methodology of REST?

Read on to find out which framework will be the best fit for your product.

If you’re a marketer or product manager, some of this language may be a bit confusing. What’s an API? What’s a server? What’s a computer?

Well, this article won’t explain the last question to you, but let’s do a quick refresher for everything else.

An API– short for Application Programming Interface– is an information waiter that ferries data between the front end of your application and the back.

Much like a waiter carries food from the back of house to the restaurant’s hungry patrons, an API carries data from the back of the app (the server) to the front of the app (the website or mobile app the client consumes).

Different APIs follow different sets of instructions. We can imagine several different strategies for how a waiter might bring food to the people that want to eat it.

A waiter could collect all the food in the kitchen and let the customer choose what they want at their table, like a one-man buffet. A waiter could bring only the Italian food, or the sandwiches, or the fruit, and let the customer decide. Or a waiter could bring exactly what the customer asked for when they ordered.

Picturing these scenarios is a good way to prepare for thinking through the differences in REST and GraphQL.

In the modern web, there are two main frameworks developers use to query and mutate data.

In one corner there is GraphQL, a scrappy young query language designed by Facebook engineers in 2012.

GraphQL’s killer feature is its ability to retrieve exactly what the user asks for without any extra data. It can deliver a complex, custom query to the client with only one visit to the server.

In the other corner is REST, a grizzled veteran of decades on the enterprise internet.

REST is a simple API framework with a low learning curve. It revolutionized the open web when it was released in the early 2000s. With REST a user can get, post, update, or delete data by visiting a given URL and adding a few specific instructions.

REST’s greatest strengths are its age and stability. Because it has helped the internet move data around for decades, there’s a great deal of support built up around it. This infrastructure helps with caching, security, and gives us a larger pool of developers that know how to work with it.

Which of these two frameworks is right for you depends in large part on the software you’re developing and the team that will build and maintain it.

Let’s learn some more about the specifics so we can make an informed decision.

REST, short for Representational State Transfer, is built around the idea of URLs and resources. According to REST, they’re pretty much the same thing.

Each set of resources in a REST API– commonly called an “endpoint”– is a URL that you can visit in your browser.

For instance, try visiting this link to the SpaceX API. It returns a list of crew members for the Dragon space shuttle, displayed as a wall of ugly computer text. Of course, it’s not pleasant to look at, but that’s because it is meant to be read by a computer.

If you take a look at the URL in your browser window, you’ll see the “endpoint” of the API request.

Change “crew” to “launches” in the URL and hit enter. You’ll now see all the launches in SpaceX history.

Each URL endpoint in a REST API is a different set of resources. The crew dataset “is” the crew URL endpoint. This makes for a simple framework to wrap your mind around, but the simplicity comes with some drawbacks.

What if we wanted only a list of the presskits that accompanied a given SpaceX launch? In a conventional REST system, we would first need to get the entire dataset from the “launches” URL, then filter out the presskits on the client side.

As you might imagine, this strategy can get complicated pretty quickly. What if we had a page where we wanted to display the launch information next to the crew information, with some data about the payloads at the bottom of the page?

We’d need three separate requests to the server.

This can make for a slow program with many developer headaches!

Facebook invented GraphQL to deal with these sorts of problems.

As Facebook was beginning its transition to the mobile internet in the early 2010s, it soon realized a REST API would not be up to the challenge.

Because each endpoint only returns a static chunk of data, the engineers would have to juggle a handful of endpoints any time they wanted to return a dynamic dataset. This would not get the job done.

To be able to handle the incredibly complex data involved in a newsfeed–and to make that data quickly appear on a phone!– Facebook’s engineers began inventing a new query language.

In this new language, highly specific, customizable requests would be sent to the server. No matter how complex the data requested became, the server would always be able to return the data in a single trip.

In the next decade, this Graph Query Language would go on to take the development world by storm.

Let’s keep using the SpaceX example to see what problems GraphQL solves. To get launch, crew, and payload information in a single go, the client would write a custom query in a simple syntax asking for each item. In a few lines, a query would return all the data in a single, uniform package.

This allows frontend engineers to write scalable code without juggling requests from many different endpoints. New product features can be tested quickly, without needing to write new backend code.

In a few short years, GraphQL has become the go-to query language for startups and innovative apps looking to scale at fast speeds.

Check out this pro/con overview of the REST API. The standard for APIs since the early 2000s, REST is a tried-and-true method with a stable, secure following.

REST’s advantages largely stem from its history of success in the industry. When the majority of the internet uses the platform, you know you’re in good hands.

The cons are also consequences of its age and simplicity. REST is getting older and will be harder to implement in newer technologies as time goes on.

GraphQL is ideal for software that rapidly iterates, like one you might find at a startup. For developers who know how to use it, it also provides a more streamlined experience.

All in all, GraphQL is worth seriously considering for any company that wants to stay on the cutting edge. It is custom-built for fast-moving, flexible applications.

However, this freshness is also the source of most of its downsides. Though it’s a proven technology, GraphQL lacks the surrounding infrastructure of REST.

There is no one-size-fits-all answer to the showdown of REST vs. GraphQL. However, given some information about your project, there are some pointers we can offer.

If you’re a young company working in a fast-paced, innovative field, you may want to choose GraphQL. Because it is built to be iterated upon, you’ll be able to create frontend prototypes much more quickly than you could with REST.

Does your app have many relational or nested fields? If your data is linked to itself in deep, complex ways, GraphQL is almost certainly the better choice. Needing to stitch together multiple REST endpoints in such a scenario could become a nightmare.

If you’re operating a software business on a tight budget, GraphQL may not be the best choice. Because it has a higher learning curve, and its error messages are usually harder to troubleshoot, you’ll need skilled engineers to build and maintain a GraphQL API. If you can’t afford this, a REST API may be a better choice.

Without expert level hardening, GraphQL can be vulnerable to DDoS attacks. A hacker can execute an expensive, deeply nested query a few dozen times on a GraphQL server to crash it.

While this vulnerability can be fixed up by any seasoned security professional, it’s still worth considering. If you’re working with cheap freelancers, a REST API might be the better choice.

Software that requires smart bandwidth usage, such as Android, iOS, or Internet of Things applications, will be better served by GraphQL.

GraphQL’s performance vs. REST is significantly faster since it only makes one trip to the server per request. This difference is very stark on mobile apps.

Given the rapidly changing nature of web development, it’s smart to start a project with an eye on what the landscape will look like a couple of years from now.

GraphQL is charging boldly into the future. Its weak points are being shored up with new tools and support systems as it continues to grow in popularity. As mobile devices take up a bigger and bigger share of the market, GraphQL’s ability to save on bandwidth will become absolutely vital to the apps of the future.

Meanwhile, REST’s problems will only get worse as software gets more complex. Remember, Facebook needed to invent GraphQL because their software was too advanced for REST to handle comfortably.

Keeping the future in mind, it might be wise to bet on GraphQL for your next project.

GraphQL vs. REST is not a one-sided issue, but a complex environment that mirrors web development as a whole.

No one tool is the best for every job. The best engineers and designers know how to tailor their tools to the task at hand. That being said, in the fast-moving tech world, you need to be able to keep up with the newest frameworks and techniques.

EB Pearls is a world-class mobile development agency with proven expertise in GraphQL and other cutting-edge technologies like React Native, Swift, and Flutter.

Don’t leave your software in the hands of outsourced labourers or outdated technologies. Your brand is too important. Reach out for a free consultation today.