Your mobile applications and web applications need to get their data from somewhere, and that somewhere is most often your API layer. So how you design and build your APIs will have a big impact on the success of your mobile and web applications and therefore on the happiness of your customers.
One key decision in the design of your API layer is whether to choose REST or GraphQL. Like all architectural decisions, there is no one-size fits all; you have to weigh your specific business, product, and technical goals against the merits of these two popular alternatives. Whereas REST emphasizes creating unique endpoints for different resources, GraphQL provides an expressive query language for accessing interrelated resources via a single endpoint. There are a lot of great posts on the internet that attempt to comprehensively compare and contrast REST versus GraphQL, and I recommend that you read them all! 🙂 This post has a more modest goal — we will discuss a few criteria to consider that can help you determine whether GraphQL might be a good fit for you and your application architecture.
It is probably safe to say that REST is the default way to build APIs in our modern era. The RESTful pattern provides a suite of best practices that help API designers build useful, legible APIs in a fairly standard way. There are a lot of great REST APIs out there powering the internet. That said, GraphQL has been around for a decade now, so while it still may not be as widely adopted as REST, it is certainly no longer the new kid on the block.
One important characteristic of GraphQL is that it is designed with a schema and type system in mind. This has important implications for how your application interacts with your API. This schema-first approach and GraphQL’s expressive query language put more control in the hands of the client application developers. That can make a big difference in the efficiency of the overall development process as well as the performance and quality of the final product.
Here are a few questions to ask yourself when evaluating whether GraphQL might be a good solution for your application architecture:
Are you building a brand new product or a proof of concept? Are you going to change your mind a lot? Are your requirements rapidly evolving? Will the presentation of the data will be continuously evolved and iterated upon?
If so, GraphQL’s schema-first approach can be very appealing. You can design your GraphQL API to express the data and relationships without having to predict upfront exactly how user-facing applications will consume your data. The application developers can then choose what data they need when they need it. This allows for ease in adding and subtracting application features without having to refactor and redeploy your APIs constantly throughout the product development process. This can really accelerate your product development process and thereby your speed to market.
Are you building a high-performance mobile app that will be sensitive to bandwidth restrictions and slow connections?
If so, it will be important to optimize what data you retrieve and how you retrieve it. GraphQL offers the client application developer a lot of flexibility when specifying what data needs to be retrieved in a single call. That can mean traversing an object tree from reference to reference in a single call instead of the multiple calls that might be required using REST APIs. And that also means only getting the bits of data that you absolutely need for your app to work. No extra cruft in the response.
Does the same data need to be presented in a variety of different ways throughout the application?
GraphQL provides a client application with an easy way to specify which particular bits of data to retrieve. Likewise, there are good client libraries for caching data so that cached data from one call can potentially fulfill future overlapping data requests.
Are you planning to use a strongly-typed language in your mobile or web application?
If so, that should naturally play well with GraphQL’s emphasis on schema and type definitions. You will likely reap valuable developer efficiency benefits building and maintaining your app.
Are you trafficking in a lot of user-specific data? Is edge-caching (e.g. with a CDN) a lot of unauthenticated content a low priority for your application?
If so, GraphQL might be a good fit. While edge-caching of content is certainly possible with GraphQL, implementing it is slightly more complicated than it would be with REST APIs. This is due to GraphQL’s heavy reliance on the HTTP Post method and on the HTTP 200 response. If edge-caching is not a priority, then you can take advantage of GraphQL’s many merits with little trade-off. If edge-caching is a priority for your application, you can still explore using GraphQL, but just make sure that you address and solve for your caching needs upfront.
This is by no means an exhaustive list of considerations. But if you answered ‘yes’ to a few of these questions, you might want to further explore using GraphQL for your application architecture. GraphQL might be right for you.
