Popular posts

CommentGraphQL vs REST

Subham Sahu

Time.

Aug 4, 2022

Thank you for this nice article. I would like to add a few more things:

In graphQL, we have an introspection query, which is really handy during development. (Don't forget to disable it in prod 🥲).
One of the lesser talked things about graphQL is data modelling. For Apollo cache to work efficiently, we must ensure that the data modelling is done nicely. If you ensure that you're not using any antipattern then usually it's safe. I've faced this issue earlier. (maybe I should document it? 🤔)
REST is faster: GraphQL does type checking, and all and thus they're slower than REST. But it makes the system less prone to errors. (There're tradeoffs to be made).
Problem of N+1 queries: We might need to use the dataloader pattern to solve the N+1 issue, which is an additonal implementation overhead. Even after using dataloader pattern the number of queries needed to resolve one request will be greater than one simple query we need to write in REST. But do note that, the number of customized endpoints are less in graphQL, and we've granular control over data fetching, which are few pros.

ÁK

Ákos Kőműves

Full-Stack Developer and Writer

Aug 4, 2022

Very good points Subham, a few thoughts:

3) I always do some kind of validation on my REST endpoints as well - mostly with AJV. I haven't measured which one is faster but in my case, both REST and GraphQL have the overhead of validation - but I don't think that's a bad thing.

4) I actually avoided the N+1 queries with GraphQL, this was one of the reasons why I started using it. ie before I used to fetch multiple projects and recent history for each project on a dashboard - now the entire thing comes through a single query.

Thank you for your insights! 🙌

Ákos Kőműves ; Thank you for the follow-up.

always do some kind of validation on my REST endpoints as well - mostly with AJV.

True. But please note that the graphQL validation is limited to only type checking. Say there is a mutation where you need a specific field to always be an integer greater than 5. This additional validation needs to be implemented inside the resolver. In the case of REST, you could've used libraries like yup for both type checking and additional validation.

I actually avoided the N+1 queries with GraphQL, this was one of the reasons why I started using it

You got me wrong. You're mentioning that "graphQL helps us in ensuring that data fetching is exact (neither over fetched nor under etched), and we can do it in a single query from client".

I was talking about the number of database queries in resolvers. Say we have a Countries and Cities table. Clearly, there's a one-to-many relation.

Assuming there're x countries and everyone has c1, c2... cX cities respectively.

If I ask for all countries and their cities, then without using the data loader pattern, the following will happen in graphQL:

fetch the countries.
for every country's city, fetch the details.

Total number of database queries: 1 (to fetch countries) + c1 + c2 ... cX

With data loader, it will be: 1 + x database queries

If you provide a single endpoint (like in REST), the number of DB access will be just 1. (using joins).

By the way, please note that I equally adore GraphQL. (Although my arguments might sound overwise 🥺). Maintaining software is a big challenge, and this is where GraphQL shines.

Search Hashnode