Support Evented services

[viktorklang]

Being able to emit events to be consumed by other services/endpoints as a part of command processing, and then being able to declare/autogenerate that an endpoint is able to receive certain kinds of events, either by having a transformation from an event to a command, and use the existing gRPC endpoints, or having to implement a specific endpoint signature to be able to receive events of that kind.

Implementing support for this will require a bit of R&D

[viktorklang]

One possibility is using CloudEvents for this.

[akramtexas]

@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 😄

[viktorklang]

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

[akramtexas]

@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 ⛏

[viktorklang]

@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. :)

[akramtexas]

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

[viktorklang]

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

[akramtexas]

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.

[akramtexas]

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

[Leila-SJ]

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