Support Evented services about cloudstate HOT 10 OPEN

@akramtexas That's for the eventsourcing parts. Those events are not necessarily intended for anything but internal consumption. Think about "Evented Services" as being able to consume and produce events coming in and going out externally. :)

from cloudstate.

@akramtexas No problem :) Just want to spare you some time & effort :)

from cloudstate.

One possibility is using CloudEvents for this.

from cloudstate.

@viktorklang - I would like to dig into this and figure out a solution for us. Does that work? Provided, of course, that this issue is still on our community radar 😄

from cloudstate.

@akramtexas Please do! We can raise this topic in the inaugural contributors' confcall next week

from cloudstate.

@viktorklang Awesome, thanks! I can't wait to throw myself at this 🆒 stuff.

• While doing a decidedly preliminary skimming-through of our source (and speaking of the possibility is using CloudEvents), I see some "hooks" already in place, for example this one in /cloudstate/java-support/src/test/scala/io/cloudstate/javasupport/impl/eventsourced/AnnotationBasedEventSourcedSupportSpec.scala:

  "allow emiting events" in {
    val handler = create(new {
      @CommandHandler
      def addItem(msg: String, ctx: CommandContext) = {
        ctx.emit(msg + " event")
        ctx.commandName() should ===("Add Item")
        Wrapped(msg)
      }
    }, method)
    val ctx = new MockCommandContext
    decodeWrapped(handler.handleCommand(command("blah"), ctx).get) should ===(Wrapped("blah"))
    ctx.emited should ===(Seq("blah event"))
  }

...and this one /cloudstate/java-support/src/test/scala/io/cloudstate/javasupport/impl/eventsourced/AnnotationBasedEventSourcedSupportSpec.scala:

        if (jsonClass.getAnnotation(classOf[Jsonable]) == null) {
          throw SerializationException(
            s"Illegal CloudEvents json class, no @Jsonable annotation is present: $jsonType"
          )
        }

• It's time to dig in ⛏

from cloudstate.

@viktorklang Gotcha, that makes sense. Plus I thank you for keeping me honest :)

from cloudstate.

Here's a summary of some recent work in this area:

• Adding an additional inflow of Commands.
• Passing those into the same processing as commands coming in via gRPC or HTTP+JSON.
• For the first PoC:

1.  Sending constructed HttpRequests in
   

2.  Then getting the HttpResponse
   

3.  And then sending it into the out-topic
   

• The CloudState proxy will have to be able to read the event source declarations in the proto of the user function, to wire things up.
• Invocation via events should look, to the user code, like responding to any request. The response can then be directed, by the proxy, to some other configured topic.
• In summary, at this time, I'm working on encoding the logic (again, by way of the R&D required for this PoC) through some sort of a driver that can plug in to an extension point of CloudState.

from cloudstate.

• More (implementation) details can be found on my feature branch, which is a fork of CloudState master branch ⛏

from cloudstate.

Based on a grooming session with @jroper and @michaelpnash, its confirmed this story has been developed but needs documentation.

from cloudstate.