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:

1. fetch the countries.
2. 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.

Got you Subham Sahu for the number of queries - I thought you were talking about the number of GraphQL queries.

GraphQL isn't perfect either but for what it meant to fix - mostly to fetch the correct payload for tons of different devices without having to implement different API endpoints or conventions (like JSON:API) and without causing too much overload for backend developers.