Hey all,
I’m finally diving into the projection functionality of EventStore and it’s pretty cool. I didn’t much like creating it in app code; this was much easier. But before I go too far in the wrong direction, I’m wondering: what is the intended use for this particular implementation of projections? For example, am I meant to subscribe to state changes (not yet sure if that’s even a thing) so that I can push those as upserts to an external store and then use that as the query model? Or is it intended to query directly from ES as if it were a store (i.e. cqrs application uses projections as a query model or via proxy)?
Sorry, I mean to say what is the intended usage not ‘use’. I don’t mean to unintentionally question its purpose.
reindexing stream and calculating things on top such as counts etc. It is obviously not intended to be what many would consider a normal read model
Oh are those calculated on demand? I thought it was just a running process that had current state available for that point in time.
So projections can be subscribed to then (so that I can transfer the state to a database)? I was just about to start poking around in the client today to look for that.
You can do this, projections are a Turing complete model. You even emit other events based on events you receive such as TransferAccepted->BeingbankTransfer
Not saying you should but you can.
Cool. I’ll take a swing at it today. I’m assuming at the moment that it works just like any other subscription. We’ll see how it goes 
I have similar consideration about “right” usage of ES projections. Here is our use case scenario:
We use $ce streams subscriptions to build our read model. This approach is working quite well but it has one limitation. It is not possible to use events from different category streams.
Our first idea was to use $all stream subscription but after some performance tests we decided to abandon this method. The amount of data which was transfered between ES and the client was huge and almost all received events were skipped in the client (there were internal ES events).
To decrease the number of events transfered between ES and the client we`ve decided to use ES projection to filter data.
We are considering to use continous projection based on $all stream which will check event streamId. If events streamId starts with specified pattern then we link that event into new stream. The intention of this new stream is to store all our business events. In the result well be able to do read model in the same way as we do now.
We know that ES was intended to handle millions of streams but we are not sure how itll behave if well change the spreading vector and we`ll put all events into single stream. Is it intended use of custom projections?
Thanks in advance for the answer.
W dniu piątek, 5 stycznia 2018 19:02:51 UTC+1 użytkownik Denny Crane napisał:
The cost of streams is tiny. Each costs about 30 bytes in the index.
So 1 stream with say 1m events in it is 30 bytes. 1m streams with 1 event in each is 30MB.
Thank you for your answer.
I assume that it is right usage and storing all events inside one stream (and then creating many from stream subscriptions) will not influence badly for the performance of the whole cluster?
W dniu czwartek, 1 marca 2018 13:58:40 UTC+1 użytkownik Greg Young napisał:
Whether you have 1 stream or 1,000,000 streams does not have any real effect (with the possible exception of a hash collision causing a slightly slower read which is an interesting but unlikely edge case).
Thank you for confirmation!
W dniu czwartek, 1 marca 2018 14:14:16 UTC+1 użytkownik Greg Young napisał: