SIP: CloudEvents HTTP for spin SDK#398
Conversation
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
|
Related to #394 |
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
| }; | ||
|
|
||
| /// A simple Spin event component. | ||
| #[event_component] |
There was a problem hiding this comment.
One small nit / aesthetic preference. Can we call this macro cloud_event_component and the module in the sdk exposing utilities cloud_event?
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
|
I have restricted the scope of this SIP to only implement spin SDK that adapts CloudEvents http binding, per our discussion at the community meeting. @radu-matei @lann |
|
Some interestings future SIPs are
|
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
radu-matei
left a comment
There was a problem hiding this comment.
I have a few comments, but this is a great start, thank you so much!
| 2. Reusability: you can reuse the same event components with different protocols bindings, such as AMQP and Kafka. | ||
| 3. Chaining: you can chain multiple event components together since they share the same component signature. | ||
|
|
||
| #### CloudEvents trigger |
There was a problem hiding this comment.
Is a trigger still relevant for the SIP?
There was a problem hiding this comment.
No, as I put this in future considerations.
| sink = "http://localhost:8080/someresource" | ||
| ``` | ||
|
|
||
| Note that the sink address is only used when the component is invoked. The component will make a outbound HTTP request that includes the CloudEvents to the sink address. No newline at end of file |
There was a problem hiding this comment.
Is a "sink address" specific for HTTP?
What is the default way of returning a result from a CloudEvents invocation?
For example, if there is an invocation triggered by an AMQP event, what is the expectation for the result?
Should the component itself make outbound requests (be those HTTP, or publish messages), or is it expected that the underlying runtime should do something with the returned event data?
There was a problem hiding this comment.
yeah forgot about the sink proposal. I was thinking to let the Spin runtime to send events to sinks, which are addressable. But now it makes more sense to just allow user to use outbound-http-cloudevents to send events.
Signed-off-by: Jiaxiao Zhou <jiazho@microsoft.com>
|
@Mossaka I did a small write-up for my thoughts around CloudEvents in Spin in #394 (comment), let me know what you think. |
|
I will update the SIP to reflect on the discussion on #394 . In particular, the implementation of CloudEvetns "feature" is quiet large, and I want to break it down to several small SIPs. |
Signed-off-by: Jiaxiao Zhou jiazho@microsoft.com