I was introduced to GraphQL when building this Blog with Gatsby.
It’s been a few years I started to some value in GraphQL. Ask what you want and get what you want seems to be the most optimal way to transfer and back and forth.
Also, providing a single endpoint makes it easier to find things rather than looking for other end points.
Then, you run into other challenges. When dealing with a setting object, this forgives bad design. A well modularized settings may be more efficient when sending small/complete check over bits of pieces over the net work multiple times.
I think GraphQL solves changing one setting at a time - who wants to have a save/submit button these days (other than XBOX privacy setting page).
For such a small update, no longer the way of building an object but rather a setting in a value with a small update and retrieving set of values at first.
More challenge comes as settings can be updated by other users, devices at the same time. Querying for a value and updating it doesn’t guarantee it’s all synced. There will be more work to ensure settings are synchronized or ask for forgiveness by showing stale data.
So then, GraphQL must be focused on scalability (performance) at the cost of more overhead to handle changes.