No mention of what I see as the biggest con of GraphQL: You must build a lot of rate limiting and security logic, or your APIs are easily abused.
A naive GraphQL implementation makes it trivial to fetch giant swaths of your database. That's fine with a 100% trusted client, but if you're using this for a public API or web clients, you can easily be DOSed. Even accidentally!
Shopify's API is a pretty good example of the lengths you have to go to in order to harden a GraphQL API. It's ugly:
https://shopify.dev/concepts/about-apis/rate-limits
You have to limit not just number of calls, but quantity of data fetched. And pagination is gross, with `edges` and `node`. This is is straight from their examples:
{
shop {
id
name
}
products(first: 3) {
edges {
node {
handle
}
}
}
}
Once you fetch a few layers of edges and nodes, queries become practically unreadable.
The more rigid fetching behavior of REST & gRPC provides more predictable performance and security behavior.
A naive GraphQL implementation makes it trivial to fetch giant swaths of your database. That's fine with a 100% trusted client, but if you're using this for a public API or web clients, you can easily be DOSed. Even accidentally!
Shopify's API is a pretty good example of the lengths you have to go to in order to harden a GraphQL API. It's ugly:
https://shopify.dev/concepts/about-apis/rate-limits
You have to limit not just number of calls, but quantity of data fetched. And pagination is gross, with `edges` and `node`. This is is straight from their examples:
Once you fetch a few layers of edges and nodes, queries become practically unreadable.The more rigid fetching behavior of REST & gRPC provides more predictable performance and security behavior.