[sourcesmith]

In reality, that would be GET /user GET settings; the cost for the unneeded associated fields at that point of time is typically not significant for many backends as they stored in aggregate and text based responses compress well.

If the data is not particular dynamic then you can cache the entire representation deriving a future benefit.

Graph base queries tend to lend themselves to adhoc query patterns and I would be concerned about unpredictable patterns of loading. If the backend store is distributed then graph QL looks more attractive to me. If the datastore stores related attributes in aggregate there seems to be little benefit since different parts of an adhoc graph would different levels of 'cachability'.

I have found an application for GraphQL in storing soft-defined triggers or other criteria on data.