kalix-javascript-sdk
kalix-javascript-sdk copied to clipboard
Forwarding and effects
@ennru commented on Thu Feb 04 2021
The docs try to separate the concept in https://docs.lbcs.dev/developing/effects.html from the usage details for Java and JS.
The docs could be more clear that these constructs operate on the single entity type within a service, forwarding and effects reach out to other instances (with different id) of the same entity.
The code examples would benefit from a more complete example especially as the referencing uses Strings which are not explained anywhere.
@ennru commented on Thu Feb 04 2021
Update: According to @pvlugter it is possible to forward to a different entity type within the same service.
@rstento commented on Fri Feb 05 2021
Currently have some questions out to @jroper to provide some realistic use cases.
@jroper commented on Sun Feb 07 2021
Some examples:
- When processing an event stream (perhaps from a remote topic, or from an event sourced entity), you may want to update an entity. That entity can't receive the events directly because the entity id on the events may not match the id of the entity you want to update. So, instead, you subscribe to the event stream using an action, and for each event, extract out the id, and then forward to the entity that with that id.
- After persisting an event on an entity, you may want to publish a push notification (eg, for mobile devices, or to clients with an active watching connection) to relevant users to inform them that the entity has been updated (the Akka serverless management-api backend does this everywhere). This would be an example of where to use a side effect, and in this case, the side effect may be calling an action that calls out to the remote Android and/or iOS push notification service.
Side effects are analogous to Akka persistence side effects:
https://doc.akka.io/docs/akka/current/typed/persistence.html#effects-and-side-effects
@ennru commented on Mon Feb 08 2021
The concepts around this start to settle in for me now. One problem here might be that Akka Serverless does not document "Actions" nor "Eventing" (processing an event stream).
@rstento commented on Mon Feb 08 2021
You are correct, Enno. The AS doc doesn't document actions because when I pulled info from the OSS doc, it wasn't there: https://cloudstate.io/docs/dotnet/actions.html
And, I think Eventing is something that we don't yet support in AS, but is on the roadmap soon.
On Mon, Feb 8, 2021 at 3:25 AM Enno Runne [email protected] wrote:
The concepts around this start to settle in for me now. One problem here might be that Akka Serverless does not document "Actions" nor "Eventing" (processing an event stream).
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/lightbend/cloudstate-docs/issues/339#issuecomment-775002308, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFOUG6Z4K5JWHYMNNVOEXDTS56UW3ANCNFSM4XCKYZLQ .
@rstento commented on Mon Feb 08 2021
Thanks @jroper!
@rstento commented on Mon Feb 08 2021
Another question, the example in the Java section uses ctx.forward
but, the method name in the interface is thenForward:
https://cloudstate.io/docs/javascript/_attachments/api/module-cloudstate.EventSourced.EventSourcedCommandContext.html#thenForward__anchor
I searched the Javadoc for a method named forward
and I didn't find one. Same thing in JS, thenForward.
@pvlugter commented on Mon Feb 08 2021
For Java, forward
is the correct method. In the docs, which links to the javadoc.
https://cloudstate.io/docs/java/effects.html#forwarding-command
https://cloudstate.io/docs/java/_attachments/api/io/cloudstate/javasupport/ClientActionContext.html#forward(io.cloudstate.javasupport.ServiceCall)
Yes, for JavaScript, it's thenForward
@retgits commented on Mon Feb 08 2021
out of curiosity, is there a reason for two different method names?
@jroper commented on Mon Feb 08 2021
@retgits I don't think there's a good reason. The JavaScript API was created first, and it was called thenForward
. Java API was created second, and probably, when I created it, I forgot that I called it thenForward
in the JavaScript API, and called it forward
in the Java API. We can rename it in either API if we want it to be consistent between the two languages.
@retgits commented on Mon Feb 08 2021
I think it would be good to be consistent across languages (which of the two we decide on doesn’t matter as much) given it’s our API.
@rstento commented on Wed Feb 10 2021
@ennru, since you have a better understanding of this now, would it make sense for me to submit a PR with my edits and once it is reviewed and merged, you can add what you think is still missing? Or would you prefer to get together to discuss it so that I can do a more thorough job in this PR?
@pvlugter commented on Mon Apr 12 2021
Deprecated thenForward
and added forward
to the JavaScript SDK in https://github.com/lightbend/akkaserverless-framework/pull/404
@rstento commented on Tue Apr 13 2021
Thanks @pvlugter, reopening this to remind me to change the name to "forward"
@ennru commented on Tue Apr 20 2021
We aligned the Java API for forwards and effects now with how Actions do it. https://github.com/lightbend/akkaserverless-framework/pull/439
I'll rework the docs accordingly.
@ennru commented on Thu Apr 22 2021
Updates to the docs in https://github.com/lightbend/akkaserverless-docs/pull/443
The JavaScript APIs are being aligned in https://github.com/lightbend/akkaserverless-framework/pull/462
@rstento commented on Wed May 19 2021
@ennru, I belive this has been fixed?
@ennru commented on Fri Jul 02 2021
No, there are still todos for this in https://docs.akkaserverless.dev/javascript/forwarding.html
@rstento commented on Thu Jul 08 2021
@ennru @patriknw, could one of the developers help out with the todos in the Javascript SDK for this page: https://docs.akkaserverless.dev/javascript/forwarding.html? I can't transfer the issue to the SDK repo because you can't transfer from a private repo to a public one.