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.