Why You Should or Should Not Use GraphQL

GraphQL, the open source technology originally backed by Facebook has continued to gain momentum since its release in 2015. Some big names have adopted it as an architectural style for their APIs including GithubTrack this API, YelpTrack this API and ShopifyTrack this API. If you’ve gotten caught up in the hype then it’s easy to think that GraphQL is the way to go when developing your next API. As with any technology though, it has its strengths and weaknesses. The team at Honest Engineering took a look at some of the pros and cons of GraphQL.

Why You Should Use GraphQL

The article lists four strengths of GraphQL, the first among them being that it is a good choice when building rich UI/ UX based mobile applications. These applications are often used over slow networks and GraphQL helps you load only what you need thereby helping to preserve the User Experience.

Reason number two is that GraphQL can help you handle complex schemas. Perhaps your application is based on a schema that uses multiple nested models and associations. If so you are likely to face complex queries, an area that REST can be weak in. GraphQL on the other hand is a Query Language so it can access nested objects with only a single API Request and return the structured data back in JSON.

According to the authors, GraphQL provides two features that make it ideal for Microservice orchestration. The first is that it allows you to abstract your RESTful API and provide a unified and optimized public API of your microservices. The result is that you can better handle future Versioning of your APIs. The second feature is schema stitching with is when you create a single GraphQL schema from multiple underlying GraphQL APIs. Both features help to hide backend complexity from clients.

The final advantage of using GraphQL is that it can help support a better developer experience for your team. This includes it being a descriptive language that can handle complex queries, the ability to simplify the loading of state management, and the fact that you are manipulating types instead of JSON data.

Why You Should Not Use GraphQL

Of course GraphQL isn’t a silver bullet. There are some cases where it will be a great choice and others where it won’t work as well. Reason number one then is obvious, you should never choose GraphQL simply because it is a hot new trend. You need to understand your use case and then figure out what architectural style best fits.

The second reason to not use GraphQL is if you believe that it is going to solve all of your performance issues right out of the box. You still need to identify bottlenecks and optimize the performance of your API in order to get the most out of GraphQL.

Lastly you shouldn’t assume that GraphQL is a replacement for REST and therefore is a default choice for your API. They are different technologies and are suited for different uses. For more complex data exchanges, GraphQL works great but for simple cases such as a read-only API based on a flat schema, REST will get the job done.

Be sure to read the next API Design article: Examining the Construction of Outstanding APIs

Original Article

Why use GraphQL, good and bad reasons