5 ms·

GraphQL-enabled event sourcing engine

89 points by yrashk 11y ago

derekdahmer 11y ago
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
- tehlike 11y ago
  also consider checking: https://geteventstore.com/ https://geteventstore.com/ Greg Young (of DDD fame) is the founder
- pramodliv1 11y ago
  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
  - djKianoosh 11y ago
    Also links the video you linked: https://github.com/milinda/kappa-architecture.com https://github.com/milinda/kappa-architecture.com http://milinda.pathirage.org/kappa-architecture.com/ http://milinda.pathirage.org/kappa-architecture.com/
  - btown 11y ago
    That talk (which is in written form at http://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html 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.
  - deleted 11y ago
    [deleted]
- cletus 11y ago
  Isn't this just log structured storage [1], essentially? [1]: http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-structured-storage http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-stru...
burstmode 11y ago
So somebody found a new term for writing a history file. Is that really "news" ?
- karmajunkie 11y ago
  It's not a new term, and it's not merely a log. Fowlers article (linked in another post) is the shortest place to start learning about it.
pdkl95 11y ago
<body> <div id="app"></div> <script src="/js/bundle.js"></script> </body> Web pages work better when they contain more than an empty <div>.
deleted 11y ago
[deleted]
tenshi47 11y ago
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).

89 points by yrashk 11y ago

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

tehlike 11y ago
also consider checking: https://geteventstore.com/ https://geteventstore.com/ Greg Young (of DDD fame) is the founder
pramodliv1 11y ago
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
- djKianoosh 11y ago
  Also links the video you linked: https://github.com/milinda/kappa-architecture.com https://github.com/milinda/kappa-architecture.com http://milinda.pathirage.org/kappa-architecture.com/ http://milinda.pathirage.org/kappa-architecture.com/
- btown 11y ago
  That talk (which is in written form at http://martin.kleppmann.com/2015/03/04/turning-the-database-inside-out.html 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.
- deleted 11y ago
  [deleted]
cletus 11y ago
Isn't this just log structured storage [1], essentially? [1]: http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-structured-storage http://blog.notdot.net/2009/12/Damn-Cool-Algorithms-Log-stru...

burstmode 11y ago

So somebody found a new term for writing a history file. Is that really "news" ?

karmajunkie 11y ago
It's not a new term, and it's not merely a log. Fowlers article (linked in another post) is the shortest place to start learning about it.

pdkl95 11y ago

<body> <div id="app"></div> <script src="/js/bundle.js"></script> </body> Web pages work better when they contain more than an empty <div>.

deleted 11y ago

[deleted]

tenshi47 11y ago

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).