Why GraphQL: A React Developer's Perspective

Submitted May 31, 2018

Technical level: Intermediate

The hype around “GraphQL is better than REST” can be justified purely by the amount of tooling around it. With code generation, query validation, editor autocomplete coupled with an API Explorer, the life of a frontend developer has never been easier. This talk will explore how GraphQL makes the experience of a React developer better.

Outline

GraphQL is a query language that allows you to describe your data requirements in a declarative way. The shape of your request matches the shape of the response. The endpoint is always the same (Whaaat!). Let that sink in. I already feel that’s less code to be written. GraphQL is not just a tool, its a standard.

Developer Tools

By leveraging the type system, GraphQL makes it easy to work with developer tools enhancing productivity. In a typical REST API integration with your frontend, most of the following isn’t straightforward or not possible at all.

API Explorer (GraphiQL)

GraphiQL features auto-complete as you type your query into the editor and automatically generated documentation based on GraphQL’s type system. You can copy the query that was generated correctly and be rest assured that it will work. Imagine getting an API Explorer with a playground for trying out backend APIs. In the REST workflow, it would involve worrying about endpoints, request payload and response structure.

Editor Autocomplete

Like GraphiQL’s auto-completion, your favourite text editors have plugins to generate GraphQL queries on the fly with the schema information fed in. In a rapid development mode, this will allow you to focus on writing code other than worrying about integrating APIs.

Query Validation

Once again thanks to the type system, the query can be validated before sending to the server. This was never possible with the REST workflow. (Looking at you, Documentation).

Mocking

Because of the predictable query and response structure, mocking the APIs and testing your application is a lot easier now.

Reduced Boilerplate for State Management

With caching and relay/apollo client’s state management, there’s so much less boilerplate code that needs to be written. It’s all intuitive with better handling of state. If i don’t have to care about caching, then it’s already a win.

Schema Stitching

Merge multiple schemas and maintain a single API for client.

As product requirements change, the frontend developer is less tied to the backend team for changing what data they want to display on the UI, unless there is a schema change required, obviously.

I personally believe that GraphQL will become the standard way to query for data from client side for most common use-cases. 2018 is going to be an exciting year for frontend developers as more and more people start using GraphQL.