What is the line to Abusing Projections?

I’m looking for best practice here: not just possibilities.

Currently, with ESv1 - we have code that writes our projected Read Models to storage (local disk, Azure blob storage, S3, etc…). Now with ESv3 - we have projections running, that can supply that same read model.

To Date, we’re considering using projections for calculated values - counters, balances, etc. That seems like a perfect fit. But I’m tempted, to start pulling more and more read models out of disk storage, and read them from a projection.

What’s the good/bad/ugly with this? Where is that line? What rules are others following?

Thank you for the conversation!

@ScottCate

602-418-0770

Follow me on:

www.linkedin.com/in/ScottCate

www.facebook.com/ScottCateAz

www.twitter.com/ScottCate

Anyone willing to offer their opinion on this?

No helpful insight, but I too would like to know what the “Do’s and Don’ts” are for projections…

I’m currently using NServiceBus/Azure Service Bus, EventStore and SQL…

I would love to collapse my footprint to NServiceBus + EventStore w/Projections, but until I hear more on projections and take ES through more than my Proof Of Concept site, I’m in the same boat as you.

They’re mostly OK to use for things like counters etc, but be aware that projections are an unsupported beta feature which have issues with clustered operation right now - we’ll be working to fix them soon.

Obviously there’s no support for e.g. range queries so they’re not useful for replacing a large number of read models.

James

I’ve found that projections also barf on large state objects.

No concrete size, I’ve just witnessed a projection that was generating a big array stop working and throwing an internal deserialization error.

If I didn’t delete the log, I’d post it.

This wouldnt surprise me they are not intended to have giant arrays of
state... there is a hard limit of 4mb IIRC but this will give quite
interesting performance