Status Updates From Designing Data-Intensive Ap...

Event sourcing and CQRS: I think that would’ve been helpful in my last team: We had multiple databases that would be updated and no one knew if the updates they made and the computations they made were correct. Maybe having an immutable list of events be the source of truth and the databases deriving from that source of truth would’ve helped

Event sourcing and CQRS: It is an interesting idea to have an immutable list of events be the source of truth and compute materialized views on top of the events. It makes it easier track the reason why changes occur and you can also recompute the materialized view if there is a bug in the code to create it

Like I wish he went into how GraphQL takes in such flexible queries
* He claims GraphQL requires less-server side changes if there is a change in the query, but I wonder how that’s true because at some point the data services have to implement the logic to adjust to the new query so wish he expanded on that more

* GraphQL section is interesting, glad he added that
* Though I wish he went into it more than Datalog, SPARQL, or other query languages b/c I’ve heard of GraphQL more than those other languages so feels like it’s more relevant

Lmao not the author talking about some archaic language called Datalog and saying it should be more popular than it is but then tries to show off its simplicity but cannot explain it well. I see why this academic language never took off. It’s confusing af