In such cases I tend to split these kinds of things into two pieces: the part that does the communication to the client, and the part that does the business logic.

I put each in their own process, with the idea that if there is any failure in the communication process (the channel, in this case) it must mean something went quite wrong with the communication link (e.g. the network) itself and there is not much that can be done about that. The client must always be prepared for such events, so in case of failure, that’s ok.

Then the business logic part, which is where it is more common to experience bugs and recoverable errors, is run in a process separate, and therefore isolated from, the communications part.

The business process (in your case the form processor) is then monitored by the communications process (using the process monitoring that comes bundled with OTP) so if anything goes wrong there, the communications process can report back to the client or, if appropriate, try again. Often I allow some sane number of failures such as 3 before completely giving up. This also gives you a place to log the error safely, perhaps even storing the raw request for later examination (e.g. for bug fixing purposes).

This also has several additional nice side-effects: The business logic process can operate sequentially / synchronously, and the comms process can be updating the client with ping’s to keep the connection alive even when the process takes a long while. The business logic process can bang off progress messages to the comms client which can pass them on appropriately. The communications process can handle multiple requests in parallel (by spawning more business logic processes). etc, etc.

Sooo … tl;dr -> considering splitting out your business logic from the channel itself and run it in its own process

This is interesting. I would love to see some code / read blog post…

when you push to the channel you will receive ‘ok’, ‘error’ or ‘timeout’ much like http, so that api call in it self is pretty similar.

callApi(apiName: string, body: any): Observable<any> {
  return Observable.create((observer: Observer<string>) => {
    if (this.channel) {
    this.channel.push(apiName, { body: body || {} }, 5000)
      .receive('ok', (msg) => { observer.next(msg); })
      .receive('error', resp => {
          return observer.error(resp);
      })
      .receive('timeout', () => {
        return observer.error('timeout');
      });
    } else {
      return observer.error('no_channel');
    }
  });
}

How you handle the errors is also similar and depends on the UX, for GETs I usually do auto retry on error/timeout and show non blocking UI(inline spinner or what not), but the user can still nav away (of course cancel the retrys in that case). For POSTs I show an alert that there was an error and that the user should retry.

Handling the channels should be automatic in my experience - I don’t handle onError for the channel, same for the socket. Once you are connected they should reconnect if anything happens. If I crash the channel the client just rejoins almost immediately.

It of course depends on your app, a live game or data stream - you would start to handle the channel down scenario - but for these ‘api calls’ on channels the above works fine, and is handled identically to http requests.

I usually build it so you can easily swap an api call and chose to run it over http or websockets, just imagine the above function as callhttpApi, it would look pretty much the same.

So you can use channels in a very similar way as http requests.

Of course the real fun starts when you push data from the server, but all that depends on the client implementation and how data is used/stored/rerendered etc.