Is GraphQL Right for My Project?

By now you’ve probably heard the buzz around GraphQL. If you haven’t, check out the first post in our series, What is GraphQL? to get a basic understanding.

Proponents of GraphQL will tell stories of API consumers asking for exactly the data they need and getting it back in a concise package, formatted exactly as expected, and lightning-fast to boot. You’ve probably heard about queries and evolving schemas that make it easier to iterate over time and remove the headaches of deprecated endpoints that result from more typical patterns of versioning. These things are all great, but before you decide to make GraphQL a part of your own project there are a few key things to consider.

To better understand the benefits and drawbacks that might sway your decision to use GraphQL let’s discuss needs around performance, the various consumers of your application’s APIs, and the experience and buy-in of your development team.

Performance

One of the most important reasons you might consider adopting GraphQL is performance. Problems such as over-fetching of data or applications requiring multiple network requests to load can be easily addressed once your application is using GraphQL. A great example is Facebook.

The social media giant found itself grappling with the first of those issues in 2012. Adding new users to the platform was a top priority for the company, and most of those potential new users were located in areas that lacked faster internet access. Because of these slower networks, Facebook needed to cut down on the load times for their web pages. If all that was required to load a webpage was a user’s full name and email address, there was no reason to fetch all the information available on a user. When Facebook began using GraphQL, developers were able to write applications that only requested the information they needed to load, thereby decreasing page load times and improving overall application performance.

Of course, not all applications suffer a serious performance hit because of over-fetching data. Many applications do require multiple requests to load a single webpage, and in that area of performance improvement, GraphQL can still be helpful.

Consider a typical microservices architecture where you have a number of services managing different parts of your application’s data. Maintainability is made easier by separation of concerns, but your application is slow because every page of your website requires multiple HTTP requests to load. This was the case for Expedia Group. Implementing GraphQL allowed Expedia’s web pages to request everything necessary to load by hitting a single endpoint. This increased performance by decreasing the number of round trips necessary to gather the data needed by their application and simplified the developer experience by unifying the needed information under a single endpoint.

Architecture

Some more considerations when looking to GraphQL are the differing needs and the number of clients that will utilize your APIs. Native and web applications will most likely request data from your API’s in different ways and in different quantities. So it’s important to consider all the information that might be consumed by both internal and external users of Github’s API, for example.

One client might only need a small fraction of the information in the GitHub data graph because they are building a widget to visualize a commit history. Another client might need all of the available data because they are building their own native GitHub client. Using GraphQL, developers can build applications that request the data they need without requiring the server-side team to make changes to the API.

In addition, as the needs of each of the applications change as new consumers of your API arise, it’s possible that you will not need to make any changes to your GraphQL schema or your server-side code. This doesn’t mean that certain fields can’t be restricted or that your GraphQL schema can’t evolve over time. It just reduces the likelihood that changes will need to be made when compared to a more traditional set of REST-ful services.

Team

So far you have heard about technical considerations when deciding whether or not to use GraphQL, but the composition and experience of your development team are also critical in making the decision. Unlike front-end component libraries such as React and server-side frameworks like Rails, adopting GraphQL will have dramatic effects on both sides of your tech stack.

GraphQL moves control over what is fetched from your API away from the back-end team and more to the front-end team working on your application. This might free up time for your back-end team once GraphQL is implemented, but it’s important to consider whether or not your front-end team has the time to make the code changes necessary to take advantage of GraphQL. It’s also important to remember that your back-end team will shoulder some additional level of responsibility when adding GraphQL to your tech stack since GraphQL needs to be added to your API before your applications can take advantage of it.

The expertise of your team should come into play as well. Is anyone on your team experienced with GraphQL? Are they willing to help other developers learn the technology? Are the inexperienced developers on your team willing to learn GraphQL and can you give them the time to do so? For these reasons, it’s also critical to make sure you have the buy-in of your entire development team before making GraphQL a part of your application.

Summary

Deciding whether or not to adopt a tool like GraphQL has huge implications for how you and your team will go about building out a new application or reworking an existing one. A broad range of clients consuming your API’s, many complex data structures spread across a microservices architecture, and performance needs that are critical to the success of your business are a few good places to start.

But they aren’t the only things to consider—developer experience, maintainability of the application, and willingness to adopt newer technology and the rapid changes that accompany that decision are also key factors in determining whether or not GraphQL is the right choice for your project. And since adopting GraphQL will affect both the back-end and front-end of your tech stack, it is critical that you have the full buy-in of your entire development team.

In the coming posts, we’ll explore how GraphQL compares with more traditional REST architecture and share some things to try before deciding you want to use GraphQL.