Why GraphQL when I can REST?
If you’ve had to fetch data before, there’s a good chance you’ve used a RESTful conventions to get data from an API. You have also probably heard that GraphQL is another interface through which you can access your data. But why would you want to use GraphQL over your trusty old RESTful routes? To see why let’s first look at REST.
REST is a great way to structure the way we grab our data, and there’s a reason it’s used as widely as it is. It’s great for grabbing a data set specific to a certain model. For instance, if you just need to get information about a specific user, the REST API is easy and predictable. It’s easy to send a GET request to /users/:user_id, and you will be returned all of that user’s information.
But let’s say you want to display a list of users’ names , and you also want to display each user’s five favorite restaurants? If you’re not dynamically generating your API based on queries in your backend, you may have an issue here. In that instance, there’s a good chance your API has more information than you actually need in that moment. You can send your GET request to /users, but if you’re just listing the users’ names, you don’t need to know their phone numbers, or address, or height, or whatever other information is stored at that endpoint. This is referred to as Overfetching, where you end up with more data than you need.
And that’s not the only issue. If there’s no relational mapping at that endpoint, you may have to send a GET request to users/:user_id/favorite_restaurants for each user’s favorite restaurants. This is what’s known as an n+1 request, or Underfetching, where multiple requests are required to get all of your data. There must be a better way!
The great part about GraphQL is the ability to query for only the pieces of data you require. This is done through Declarative Data Fetching. Instead of having multiple and defined endpoints to request your data from, GraphQL has a single endpoint. And instead of returning model specific API endpoints, you have a Schema. A schema is a collection of Types, which you define to correspond with the data in your backend. In your schema you specify what data can be accessed, what data is required, and you can even declare who has access to specific pieces of data. To retrieve your data, you simply write queries to your graphQL endpoint that specify the data you want back.
This ends up with a little more code being written to get your data, but potentially much less data being exposed and retrieved. And with one request you can get your data custom tailored to what you need in that specific situation. You can even pass in arguments to be even more precise about the data you’re retrieving.
While there are certainly situations where REST is still the best solution, GraphQL could be an improvement in some of your projects. It’s definitely worth checking out. If you’d like to learn more about using GraphQL here are some resources.
The Fullstack Tutorial for GraphQL
GraphQL vs. REST: A Comprehensive Comparison - Alfrick Opidi
