I believe it's due to a faster performance - with the rest api, you're always ending up retrieving data from many more db columns than you need to, for any given functionality you're building. With graphql, you're decreasing the data being transmitted over the API, by only choosing just the columns you need.
.. but as an argument against my own reply, if you don't want to learn/use graphql, I think the improvement in the newest nextjs incremental static generation could mitigate the performance loss if you went ahead and just used WP REST Api. You could configure nextjs to pull data from the server every 2 minutes at the most or something like that.
You could also use SWR to serve stale state after the page time exceeds the last regen, it'll serve one stale state, and then trigger a revalidate in the background.
Hi Rob, thanks for taking the time to write this up.
A question though: Why use GraphQL instead of the WordPress REST API?
I believe it's due to a faster performance - with the rest api, you're always ending up retrieving data from many more db columns than you need to, for any given functionality you're building. With graphql, you're decreasing the data being transmitted over the API, by only choosing just the columns you need.
.. but as an argument against my own reply, if you don't want to learn/use graphql, I think the improvement in the newest nextjs incremental static generation could mitigate the performance loss if you went ahead and just used WP REST Api. You could configure nextjs to pull data from the server every 2 minutes at the most or something like that.
You could also use SWR to serve stale state after the page time exceeds the last regen, it'll serve one stale state, and then trigger a revalidate in the background.
I think it still would be wise to use GraphQL, since ISR from Next still pre-bundles the complete chunk of static props.
If you then want to slim down the REST response, you'll have to do one of the following: