Reasonable functional boundaries for projections

EventStoreDB
#1

My initial understanding of projections is to “transform” data from source streams/events into destination streams/events, potentially with a different format. However I could do this with a subscription as well, so in a way a projection could be thought of as a subscriber built-in to Event Store. That’s a stretch, I know, but I am trying to determine what the boundaries are for projections. For example, using a projection to communicate with an external resource.

We are trying to minimize number of hosted applications that we would need to budget/support and this was one idea that we wanted to float to the group. Could a projection make requests to a message queue?

  1. Is it technically possible
  2. Is it a fundamentally sound idea

Thanks,

Blake

#2

2) Is it a fundamentally sound idea

No

You could have an adapter move information into/out of streams for
projections but thats about it.

#3

That’s what my gut was telling me - but had to ask. Thanks!

#4

I should add or you could just use the streams as queues which is a
totally valid use case

#5

At this point, our approach is something like:

  • Write events to ES (duh)

  • Have mini workers/services/daemons subscribe to the streams they care about. These workers know what they’ve done, etc.

  • New messages are picked up by the daemons and written to mongo/queue/postgres/whatevs

Is this valid?

Thanks,

Glenn

#6

You could also do this with miniworkers being internal projections
once they are out of beta

#7

Any docs on those? Not having to write these workers could be huge for us.

Also, we won’t be going live for a while…when is beta over?