I didn't know what event sourcing was, but Martin Fowler's article did a pretty good job explaining it:

http://martinfowler.com/eaaDev/EventSourcing.html

If you want a more modern and concrete example, the "Turning your database inside out" talk by Martin Kleppmann is pretty good too: https://www.youtube.com/watch?v=fU9hR3kiOK0

That talk (which is in written form at http://martin.kleppmann.com/2015/03/04/turning-the-database-... for those who can't watch video) is one of the best I've seen on the subject, and it can really change your way of thinking. Our company has embraced event sourcing wholeheartedly, and it's been gamechanging for us.

One of the key benefits of always being able to re-derive the queryable form of your models from the raw event data, and one that doesn't always come across in tutorials like the OP, is that you aren't just restricted to events that map nicely to "change this specific property in my domain model" or "add a new specific object with these properties." For instance, say you're ingesting emails in a CRM, and you want to say something like "detect the company address from the email signatures, but always make sure that any manually-inputted address overrides that." But then you later change the address-detection algorithm, but want to maintain the manual-override invariant. If that code had been run at email ingestion time in a non-event-sourced paradigm, you'd need to have three-way conflict resolution between old-extraction-algorithm, new-extraction-algorithm, and manual inputs. But with event sourcing, you update the setOfAllEvents -> domainObject function and just push the code, and your data migrates gradually and naturally. And the sky is the limit with how you can combine different types of events.

Everyone loves to talk about source control and continuous integration, and we'd never dream of making the build from code version Y dependent on the build from code version X. But in data management, it's far too easy to use a non-event-sourced approach, and then you introduce those dependencies. And it doesn't have to be that way at all.

Also links the video you linked:

https://github.com/milinda/kappa-architecture.com

http://milinda.pathirage.org/kappa-architecture.com/

Isn't this just log structured storage [1], essentially?

[1]: http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-stru...

also consider checking: https://geteventstore.com/

Greg Young (of DDD fame) is the founder

Recently I created a small example of a GraphQL server (built with http://sangria-graphql.org) which is based on event-sourcing and CQRS:

https://github.com/OlegIlyenko/sangria-subscriptions-example

It does not use any event-sourcing library or anything like this, so it may be more approachable for people who are learning even-sourcing and GraphQL.

Interesting aspect of this project is that it uses GraphQL subscriptions to expose and stream the events (with Server-sent Events).