Forward and Effect to Remote HTTP Services

[sleipnir]

Hello guys!

Would it be interesting to add a forward and effects mechanism for remote http services?
In this way, a cloudstate service could forward a message to external APIs.
Let me know what you think.

Cheers

[viktorklang]

@sleipnir Do you mean instead of having the serverless function do an async HTTP-request itself?

[sleipnir]

Yes @viktorklang.
Imagine that I have to send a request there is something external to my cloudstate environment, like an external API of some client of mine sending a hook for example, in this case I need to make an http request but I don't want to have to worry about this underlying infrastructure.

[viktorklang]

@sleipnir Hmm, it would be rather straightforward, but on the other hand you sort of enter the durable distributed statemachine place (especially if you're trying to build a DAG of external interactions (think Saga Pattern).

[sleipnir]

Hi @viktorklang !

@sleipnir Hmm, it would be rather straightforward, but on the other hand you sort of enter the durable distributed statemachine place (especially if you're trying to build a DAG of external interactions (think Saga Pattern).

Yes, relatively simple. And yes, I agree about SAGA because it would basically be the SAGA pattern based on orchestration, with the proxy being the orchestrator.
We could obviously start with the simplest cases and see what others think.

But I would love it because I could switch my production systems to Cloudstate faster :)
Lol

[viktorklang]

@sleipnir You could probably implement something in the API right now and iterate on the end user experience while having the requests performed in the user function rather than in the proxy, then move the functionality seamlessly into the proxy?

[sleipnir]

@viktorklang sorry but i don't think i understand the question.
Do you want to know about my specific use case, whether it would be possible for me to make the necessary calls within the user functions?
Or are you asking me about transparency?

[viktorklang]

@sleipnir I think there are two components to this: 1) API for end users, in the different User Language Support 2) Proxy implementation & protocol definition. 1 can be implemented separately by stubbing out the need for proxy support by instead invoking something like an HTTP API under the hood. It would be interesting to contrast and explore the value of implementing it inside the proxy vs just having calls made from within the User Language Support.

Does that make more sense?

[sleipnir]

@viktorklang I believe this is a fully proxy feature. Delegating this to the user's language consistently across all languages would be very difficult.
I think that all the mechanisms and tools to do this are already in the proxy and in the protocol, I believe it is more a matter of putting the pieces together.
But both approaches have potential. What would you like to try first?

Maybe it would be interesting to mention this in the call of the collaborators and to hear a little from the others about what they think

[viktorklang]

@sleipnir I agree on the proxy feature, but what I'm saying is that it would be interesting to explore the user API first. Then once that has been explored it is much easier to implement it on the proxy side

[sleipnir]

Ok @viktorklang after your last comment I understood that. I just made one more comment about what I think.
As I mentioned, I have no problem trying any approach.

[viktorklang]

@sleipnir 👍

[sleipnir]

Hello @viktorklang what do you think of the API proposal (in this case in Java) below:

// #lookup
private final ServiceCallRef<Protocol.HttpRequest> requestRef;

private final ServiceCallRef<Protocol.HttpResponse> responseRef; //Optionally we can define a commandHandler to handle the response

public ShoppingCartEntity(Context ctx) {
  responseRef =
    ctx.serviceCallFactory()
      .lookup("example.shoppingcart.ShoppingCartService", "ItemAddedToCart", Hotitems.ItemAdded.class); //Note that here we pass the type of the class that will be sent in the body of HttpResponse.

  requestRef =
    ctx.serviceCallFactory()
      .lookup(
	  "https://some.url:4443/some/resource", responseRef);
  
  // #fire-and-forget
  requestRef =
    ctx.serviceCallFactory()
      .lookup(
	  "https://some.url:4443/some/resource"); // Without any response reference this call will be asynchronous 
                                                  // and without any commandHandler to be called later for this request
  // #fire-and-forget
  
}
// #lookup

class CommandHandlerWithForward {
    // create request headers if use
    Map<String, Object> headers = new HashMap();
    headers.put("Custom-Header", "Custom-Value");

    // #forward
    @CommandHandler
    public void addItem(Shoppingcart.AddLineItem item, CommandContext ctx) {
        // ... Validate and emit event
        ctx.forward(
	    requestRef.createCall(
	        Protocol.HttpRequest.newBuilder()
		    .setHeaders(headers)
                    .setBody(
                        // Obviously we have to note the protobuf in some way so that this object can be serialized via json.
                        Hotitems.Item.newBuilder()
			  .setProductId(item.getProductId())
			  .setName(item.getName())
			  .setQuantity(item.getQuantity())
			  .build())
		      ));
    }
    // #forward
}

In this case, I kept the user interface as close as possible to the existing forward and effects interface. I just imagined some wrapper classes to handle the request and response and some changes to the lookup interface.
This would also eliminate the need to implement a more complex state machine (like the one needed for an implementation of the SAGA pattern), not that this is not interesting in the future, but we could start with the simplest and let the user if he wishes to implement the standard SAGA by itself, since we would have exposed an api that would allow it to create more complex flows. Just building blocks for now.

[viktorklang]

Pinging @pvlugter :)

[jroper]

Yeah I've thought about this. We definitely want/need to support something like this. What I do want to make sure is that the abstractions we provide are the right ones.

Of course, there's nothing stopping you from calling a remote service directly. It does mean that the proxy is not able to orchestrate it, but at least there's nothing blocking implementing something like this today.

One thing that I'm not sure about is how useful the existing forwarding support is, I'd like to validate that both with some example use cases, as well as seeing people use it to solve real problems. One problem with the support today is, what if what you actually want is not to forward, but rather, to delegate, and then handle the response? One way to do that would be to forward to the remote service, then have it forward back. But I'm not sure that that design makes sense, it means there's a two way awareness of each other. So I think a new abstraction that was maybe "forward to this service (local or remote), and then handle the response from that service with this other call". But that's also getting very complex, and how do you maintain context between those? While it does mean the proxy is orchestrating everything, for the developer, it may feel very unnatural to do that, and the advantages of the proxy orchestrating might not outweigh that complexity.