-
Notifications
You must be signed in to change notification settings - Fork 0
Introduce Ingress service and BackgroundInvoke #19
Conversation
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.
Thanks @slinkydeveloper, the service definition looks good to me.
dev/restate/services.proto
Outdated
service Ingress { | ||
// Invoke a service and don't wait for the response. | ||
// It is guaranteed that the service will be invoked after this method returns. | ||
rpc BackgroundInvoke(InvokeRequest) returns (BackgroundInvokeResponse); |
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.
Seems like the TypeScript SDK, and the documentation calls this "one way call", we probably should align to that name here as well.
Once will standardize on the name we'll make a change across the board.
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.
You know, thinking about this a bit more, I think that it is distinct enough from the SDK to deserve its own concept.
And since it is under the ingress service, it is okay to imply call it Invoke
.
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.
So would you be fine with BackgroundInvoke
then? The reason I wouldn't call it simply Invoke
is that i can foresee in future adding a variant of this method that actually waits for the response.
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.
BackgroundInvoke will not be consistent with the SDK and the docs atm.
Lets do simply Invoke for now, because I don't have a better name, and if we would need a different variant we will change and rename.
// this field must contain the serialized Protobuf matching the argument type of the target method. | ||
// When executing requests to the ingress using JSON, | ||
// this field must contain the JSON object representing the argument type of the target method. | ||
bytes argument = 3; |
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.
That is a bit of a pity that this has to be like that, the call site becomes clunky, but that's Protobuf.
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've seen in other APIs that it's normal to use bytes
fields for nested messages for which you don't have a type definition at compile time, e.g. see the Any type
. In any case, for JSON the users will just pass the json object, so the interface will look "natural" to them.
2fc3e37
to
c50e080
Compare
Part of restatedev/restate#452