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.
Hold On, What’s an API?
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 Transports Data Like a Waiter Transports Food
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 Produce Different Results
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.
GraphQL vs. REST in a Nutshell
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: How Does It Work?
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.
REST Comes With Problems
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!
GraphQL: How Does It Work?
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 GraphQL, One Request Gets All the Data
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 API Pros
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.
- REST is simple to use
- More developers know how to use REST than GraphQL
- REST code is often more readable and tracks with HTTP protocols
- In-built HTTP error messages are specific and helpful in situations where GraphQL may not return a meaningful error message
- REST APIs can easily be cached for large speed improvements
- REST has a lower learning curve than GraphQL
REST API Cons
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.
- Delivering a static chunk of data from multiple URL endpoints can make for complicated code
- Doing dynamic queries and mutations on the server can be a developer headache in REST
- An API consumer will usually need to fetch more data than they actually need when they make a call to REST
- Engineers need to create custom endpoints in REST to return unique data for the frontend
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.
- Saves the frontend engineer the hassle of fetching extra data they don’t need
- Saves the backend engineer the hassle of creating multiple endpoints with specific shapes
- Extremely scalable (built for the Facebook mobile app!)
- Because data is not tied to the way it is fetched, GraphQL allows rapid iteration on the frontend
- Since each client request is unique and fine-grained, your backend analytics can be very specific, allowing a team to learn a great deal about what each customer does on the app
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.
- Because GraphQL is so new, it lacks some of the established support that REST has
- Caching is not as easily implemented as it is in REST
- Because a single query can be so customizable, certain styles of DDoS attacks are possible in GraphQL that aren’t in REST
- Less documentation and a steeper learning curve for new developers
When to Use REST vs. GraphQL
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.
Are You Willing to Experiment?
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.
How Complex Is Your Data Structure?
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.
Do You Have a Smaller Budget for Developers?
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.
Are You Facing APTs?
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.
Will You Be Building a Mobile App?
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.
The Future of APIs
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.
Hire the Experts
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.