Thats correct. Cloudstate User Support Libraries do implement the Cloudstate Protocol defined through protocol buffers.
You can find information about it here, where you can find the protobuf files.
https://github.com/cloudstateio/cloudstate/tree/master/protocols
and also here in more general terms
https://cloudstate.io/docs/developer/language-support/index.html
There is also a Starter Repository for Python currently at
https://github.com/marcellanz/cloudstate_python-support/tree/feature/python-support
which explains the first steps to get started, with python in this case.
... to get started I recommend to read the README.md of the project:
https://github.com/cloudstateio/cloudstate/blob/master/README.md
and especially this section, which describes the expected behaviour: https://github.com/cloudstateio/cloudstate/blob/master/README.md#common-intermediate-representation
then the protobuf files itself, as they describe what the (gRPC) services are expected to do and also which messages exist. Then, reading the existing implementations can help to understand semantics of the protocol.
- the content of
example, as the name indicates, seems to be the protobuf base for theshopping-cartTCK validation. - the content of
frontendseems to be used for JSON communication (probably with front-end apps... thus the name). - the content of
protocolis the base of the gRPC server used for interacting with the proxy. - the content of
proxyseems to be the gRPC interface exposed by the proxy to communicate with its clients.
example => is for implementing the example application, which is also used by the TCK for third-party language (and proxy implementation) validationfrontend is what is used by developers of services when they define their proto interfacesprotocol is the protocol between the proxy and what we call a Language Support, i.e. a bridge library which speaks with the proxy and exposes a native API for some programming languageproxy contains the protocols which the proxy itself speaks with the outside world.
@ChristopherAndre I've done a csharp implementation recently which I've kind of done. (ie. I haven't actually touched the TCK, and I've had to muck around with a lot of gRPC and Protobuf internals to make it work). While I've tried to stay very close to the Scala/Java APIs, I've had to adapt some things idiopathically. So, not saying it's the perfect example of how to implement another language, but it might help you see something that was done in a bit of isolation.
@marcellanz I didn't notice there was a starter kit for Python, that really helps - especially the TCK integration. I might have a crack at using it, then it would help me for using TCK on csharp. Thanks!
minikube start --vm-driver=hyperkit --memory 16384 --cpus 6
I'm trying the forward and first I create a reference on the service I would like to forward to like this:
ServiceCallRef<Ssm.SessionSetup> sessionCreationRef =
ctx.serviceCallFactory()
.lookup("com.example.ssm.SSM", "CreateSession", Ssm.SessionSetup.class);but there is something wrong with the service name (first argument of the lookup above) because I got this error in the user-container log:
java.util.NoSuchElementException: No service named com.example.ssm.SSM is being handled by this stateful serviceHowever the name looks like the right one as it is the one returned by grpc describe:
grpcurl -plaintext 192.168.64.33:31894 describe
com.example.ssm.SSM is a service:
service SSM {
rpc CreateSession ( .com.example.ssm.SessionSetup ) returns ( .com.example.ssm.SessionResponse ) {
...I did something wrong ? What could be the reason of this error ?
Regarding the forward, documentation says:
It is the responsibility of the forwarded action to return a reply that matches the type of the original command handler
but if I try to return something in my original command handler, I have an error: Both a reply was returned, and a forward message was sent, choose one or the other
Is any way to return something in a command handler doing a forward ?
@domschoen I was working with this the other day and there are a few things that I found.
1) As you found, forwarding only happens within the same user function. I think this limitation is meant to stress the importance that cross-domain operations should be event driven.
2) You can't both reply AND forward. As the documentation states, you need to have the terminal command handler do the reply on behalf of the first command handler. And, that reply must match the type of the original handler.
I just merged this PR: cloudstateio/cloudstate#158
Next steps is to add a reusable test suite so we can add more EventingSupport implementations down the line.
About the forward, at the end, it works like a charm with only one limitation: forwarding only happens within the same user function.
Let me give you what I did to finally get the return value in the original action: However the command handler method doing the forward in your entity return void:
@CommandHandler
public void createSessionWithDevice(..., CommandContext ctx) {
...
ctx.forward(call);
}in your protobuf, the command has a return type which is the same as the action you forward to:
service Device {
rpc CreateSessionWithDevice(SessionSetupWithDevice) returns (com.example.ssm.SessionResponse) {that's it !
