Noop
How can I best utilize event-driven architecture in Noop? #35
-
|
If I'm working with an event-driven application, what is the recommended practice from a "Noop-native" perspective for event streaming? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 4 replies
-
|
@nprimmer Can you clarify more about what type of "event-driven application" stack you're thinking of here? Something like Kafka, SQS, Redis Pub/Sub which are more like message brokers? Or is this like S3, Dynamo, Kinesis where these resources publish events based on changes to their state that you want to programmatically respond to? |
Beta Was this translation helpful? Give feedback.
-
|
Apologies for the lack of clarity, I had been thinking pub/sub style. But your callout of state-change-driven applications also makes me realize I don't know how we would set that up in Noop either. |
Beta Was this translation helpful? Give feedback.
-
|
Cool, thanks for clarifying. For message brokers, we currently support Redis as a Resource which can provide Pub/Sub functionality between multiple Service Components. SQS is the horizon and I'd be interested in hearing if there are any other specific message broker technologies you'd be interested in. The state-change-driven space is very interesting to me as well, but we don't have any current plans on the roadmap. We already have Input/Output with Task Components (more docs needed) which could offer an interesting approach. Like we could receive the S3 event when an object is uploaded, and invoke a Task Component with the payload in the input. It's a challenging space because it gets into Noopy ways to write software, which we are loathe to ever do unless there are no well accepted approaches and when absolutely necessary to provide significant value. |
Beta Was this translation helpful? Give feedback.
-
|
For my current-ish actual use case, Kafka and SQS serve best, but the Kafka overhead would not be a great fit for Noop. The biggest thing I want out of my message broker is permanence/replayability since I'm using it for transactional data. Unless I'm using Redis for speed and logging the transactions to a secondary datastore, I don't believe I can get that out of Redis Pub/Sub out of the box. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, that's why SQS is in my shortlist, it can bring that durability to your message delivery that Redis doesn't ensure. |
Beta Was this translation helpful? Give feedback.
Cool, thanks for clarifying.
For message brokers, we currently support Redis as a Resource which can provide Pub/Sub functionality between multiple Service Components. SQS is the horizon and I'd be interested in hearing if there are any other specific message broker technologies you'd be interested in.
The state-change-driven space is very interesting to me as well, but we don't have any current plans on the roadmap. We already have Input/Output with Task Components (more docs needed) which could offer an interesting approach. Like we could receive the S3 event when an object is uploaded, and invoke a Task Component with the payload in the input. It's a challenging space because it gets i…