-
Notifications
You must be signed in to change notification settings - Fork 249
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIP: CloudEvents HTTP for spin SDK #398
base: main
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is a trigger still relevant for the SIP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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