sourcesmith
Joined 11 years ago
Joined 11 years ago
> You'd need to define a representation of that log, which ends up being equivalent to writing a NoSQL datastore.
I think this covered by relational DBs redo/rollback/write-ahead log; whatever you want to call it.
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.