When to use REST versus gRPC versus GraphQL (Part 2)

In our previous post, we discussed the benefits and drawbacks of two of the most popular API models - REST and gRPC.

In this post, we'll highlight the final API model in our series, GraphQL. Finally, we’ll recap our learnings with a side-by-side comparison of REST, gRPC and GraphQL.

GraphQL

GraphQL is an API query language designed to provide a more streamlined and queryable API for mobile applications, GraphQL APIs are popular for implementations with highly complex schemas in which only subsets of data are needed.

It's much easier to understand GraphQL by seeing an example request and response. Let's consider the Countries List GraphQL implementation. This API exposes continents and countries as resources. Let's see what an example request and response might look like:

On the left, notice that you must indicate what fields you want to receive from the API. There's no option to request all continents without indicating what you want to know about them. In the above request, we asked for the nameand codefor each continent.

We could have slimmed down the response payload by asking only for codebut not name. The gain in this example is minimal, but consider a massive table with dozens of columns. With a REST API, a GETrequest might get everything about every record. With GraphQL the client only receives and processes the data they need.

Let's take another example, looking at the fields available when querying countries:

Fields on the countries resource as fetched through Kong Insomnia using native GraphQL support.

The following query will fetch the name, capital, and languages of all countries in Europe that use the Danish Krone as currency:

This is what the response payload looks like:As you can see, we only received two results, but we did so with a single request. This query precision is what GraphQL was created to do, and it shines when we take full advantage of filtering and choosing specific fields to return for our records.

Benefits and drawbacks of GraphQL

GraphQL lets developers be laser-focused in their queries, plucking out only the data they want.

While this flexibility is a benefit for the client, it is also a drawback for the server developer. Somebody needs to do the heavy lifting so server performance can be unpredictable. The full customization of requests also means that caching is very difficult. These difficulties do translate to a steep learning curve for API developers looking to take a GraphQL approach.

When to use GraphQL

If you anticipate there will be many ways clients will consume your data, GraphQL can be an ideal choice. Empowering API consumers may mean more work on the back-end, but it will likely make your APIs easier to consume.

Suppose your client applications need highly structured information to build out your interfaces or populate the information displayed in your applications. In that case, GraphQL can be a great way to cut down on the number of requests you need to make to your servers.

Comparing Key Differences

The decision of which API development approach to take begins with a deep consideration of your business and application needs. The following table highlights some of the key differences between the three approaches we've considered:

Conclusion

Throughout this blog series, we have seen there isn’t a one-size-fits-all approach to API development. Microservices have allowed for application functionality to be abstracted, enhanced and modified independently from other systems. If one part of your system requires a gRPC implementation, others could reasonably use a GraphQL API simultaneously, all while exposing something else using a REST design.

To learn more about the top API models and when to use them in your next project, download the "When to use REST versus gRPC versus GraphQL" eBook today!