What is the line to Abusing Projections?

EventStoreDB
#1

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

#2

Anyone willing to offer their opinion on this?

#3

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.

#4

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

#5

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.

#6

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