Reasonable functional boundaries for projections

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) Is it a fundamentally sound idea

No

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

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

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

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

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

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?