98 karma · joined December 2, 2015
> 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.
Repeatable migrations are great especially when combined with upserts in Postgres, if you keep config in your database as well.
Despite Spring being Enterprise it still scales down to simpler apps pretty well due to its modularity.
These can be build into a single jar app that is easy to build and deploy, and combined with a database migration library, maintain their own database schemas. Very, very usable.
Yes, I probably would not use Java on the frontend unless it was for a technical audience.
EOR