Home > other >  How to deliver the result of asynchronous request from back to front (Callback)
How to deliver the result of asynchronous request from back to front (Callback)

Time:01-13

Client send a request to my my service "A" then I send a request from service "A" to Camunda like "doSmthAndGet" then camunda replies "request accepted" and asynchronously calls another service "B" to process my request. After service B returns the result, Camunda will call API of my service "A" to return me this response. In what ways can I deliver this result to a web page (JS) to display to the client? I thought about a websocket, but I'm not sure if this is a good idea, because for one client such a request is sent once and after that the websocket is no longer needed. But I need some kind of "channel" to call the front side (JS) when I get a processed result for a particular client in my service "A".

CodePudding user response:

I think I understand your predicament now, instead of:

  1. Client <--> Server A <--> Camunda <--> Server B --> Results from server B on client

You have something like:

  1. Client <--> Server A <--> Camunda --> Result 'OK' from camunda on client
  2. Camunda <--> Server B --> Results from server B on Camunda
  3. Camunda <--> Server A --> Results from server B on Server A

(I now you refer to services but for the sake of this explanation I prefer to refer to the machines)

When Server X makes a requests to Server Y then Server X is technically a client as far a that request is concerned. The communciation between Camunda and your server can really only work this way because the client (server A) is also a server.

If you want to send data to a client you must either make a request from that client or first establish a two-way connection, e.g. a websocket like you suggested.

Solutions

You could declare a variable, and simply hold off responding to the initial request until "step 3" fills it with some value but I fear that this approach is prone to all kinds of errors and not sustainable.

You could still use something like this approach, but instead of holding off the initial request you rely on the client to "Check back in later". Something you could do automatically at regular intervals using JS.

The challenge with both scenarios is that you have to implement or at least account for some kind of user session logic to make sure you send the right data back to the right user. For that reason I think your own suggestion to use WebSockets is perhaps the most elegant.

I don't think it is a problem to only use the WebSocket once, and if you want you can close the connection after the whole process has been completed.

  • Related