Projections with large javascript bundles

EventStoreDB
1

Hi all.

I’m looking into using EventStore for a new project. I have some questions about versioning, and the projection runtime setup.

I would like to version my event schemas. Each event will have a type and a version field. Each type version will have an up-caster (converts an event from the previous version to the current version) and a downcaster (converts from the current version to the previous version). This way I can make a runtime conversion to get whatever version of event my service requires.

I’m hoping to be able to write projections that embed this runtime conversion system. In the handler function for each event type, a conversion will be made to the desired event version before running the rest of the handler. Has anyone tried this and does it sound reasonable?

One concern is, depending on how a projection event is processed, this could add quite an overhead to each event processing. Does the javascript bundle for each projection get parsed and loaded into memory at start up, then wait for events? Or, does the whole javascript bundle get parsed and loaded into memory before handling each event?

More generally, does anyone know of a limiting factor in javascript bundle size?

2

I would recommend against this. I have previously written about this and tend to prefer weak-schema. You can read online (look under ToC link). http://leanpub.com/esversioning

3

Weak schema makes a lot of sens. Having read this I think the versioning system I have above was over-engineering.

I’m still interested in the large bundle question though. I’m tentatively looking at writing projections in Scala and compiling to javascript with scala-js. Scala-js has a minimum bundle size of about 100kb. Having to load that for every event would be unacceptable, but just loading at boot would be trivial. (https://groups.google.com/forum/#!topic/scala-js/KFq4oDxYiPM)

4

projections are compiled in v8 not loaded per event.