Why GraphQL: A React Developer's Perspective
Submitted by Praveen Durairaj (@praveenweb) on Thursday, 31 May 2018
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.
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.
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.
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.
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).
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.
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.
Application Engineer at Hasura. Everything React / GraphQL / Postgres / Kubernetes. Recently an active OSS contributor.