JSON Patch in a projection? Is it possible to use a library in projection code?

EventStoreDB
1

Hi chaps,

First-time poster - just getting immersed in Event Sourcing and feeling like the scales have fallen from my eyes. A future with no ORM… :slight_smile:

I’ve not attempted DDD/CQRS/ES before so I apologise if this is a cardinal crime…

As well as supporting proper domain events in my store and projections, it might sometimes be useful to offer a more crud-like patching model. For instance; if the business logic, validation, etc. was applied at a higher level leaving only the need to persist the outcome in a generalised way.

I am thinking about events being instances of the JSON Patch format http://jsonpatch.com/

And for the projection to implement the corresponding application code, e.g. http://jsonpatchjs.com/

But is it possible to take advantage of such libraries in projection code?

At the moment, I’m more interested in the technical ‘if and how’, rather than the DDD ‘could or should’. But I’ll be happy to receive any opinions.

Many thanks for any advice you can offer. I expect I will have many more questions to follow and I look forward to becoming an active member of this group.

Cheers,

Raith

2

The problem with a patch is that very often it means something quite different today and one year from now.

3

Thanks for the quick reply Greg.

Yes, the per-property patching does rather tie down the model to today’s version. I fully agree. But there are some things that one simply doesn’t expect to change (eg. a model for postal Addresses).

I don’t really want to stray too far into deep-thought territory as I’ve not enough hard-won experience yet to back up my views, but…

  • What if I had an EventStore instance which stuck to all the ‘rules’, stored meaningful domain events, etc.
  • But if I often had to delve into the past, and wanted the good ES instance to drive a second more crud-y one where the domain events were reduced to property patches.
  • That second instance would be a more volatile environment, taking advantage of some of the ES benefits although obviously losing others (e.g. immutable history).
  • And it would be much simpler to interpret the events without any repeat of domain logic code, so the events could be replayed outside of ES really easily.
  • And these ‘instances’ might just be different stream in the same actual instance, with a nice set of streams projected into patch streams, projected into states.

Please don’t ask “why”. I’ve said too much - I’m too far out on the thin ice.

But still, is it possible to use large chunks of library code when building projections?

4

And another thing…

If the process changes then the old events might not be entirely meaningful either, and the code to project them would hang around to support ‘legacy’ events.

Just saying that the model and events could both be equally obsolete.

Raith

5

I see no reason not to add jsonpatch.min.js as a (3kb) one-liner to the top of your projection code, and if your particular application is just changes to a json-document-state, then it seems like a great implementation to me.

6

Keep us informed of your progress and results.

7

Will do, thanks BB.

I’ve been exploring projections to see what scope there is for structuring the code. The docs are a bit light on such matters.

I’ll post the projection when it’s working, in case it’s of interest to others.

8

I’ve seen projections written with helper functions declared like this:

var x = function() {

};

fromStream(‘myStream’)

.when({

“myEventType”: function(s,e) {

x(e.body);

}

});