
GraphQL-enabled event sourcing engine - yrashk
http://eventsourcing.com
======
derekdahmer
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](http://martinfowler.com/eaaDev/EventSourcing.html)

~~~
pramodliv1
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](https://www.youtube.com/watch?v=fU9hR3kiOK0)

~~~
btown
That talk (which is in written form at
[http://martin.kleppmann.com/2015/03/04/turning-the-
database-...](http://martin.kleppmann.com/2015/03/04/turning-the-database-
inside-out.html) 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.

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

[https://github.com/OlegIlyenko/sangria-subscriptions-
example](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).

------
pdkl95

        <body>
            <div id="app"></div>
            <script src="/js/bundle.js"></script>
        </body>
    

Web pages work better when they contain more than an empty <div>.

