I’m looking to implement SignalR through Azure API Management and the issue is that as of now Azure API Management doesn’t support different types of APIs for the same suffix, meaning that I can’t set up SignalR to work primarily with WebSocket and ServerSentEvent/LongPolling as a fallback.

I’m currently investigating how to circumvent this and am wondering whether it would be possible in SignalR to setup two different URLs in my SignalR client, one for primary use with WebSocket, and the other when using any of the fallback protocols.

My idea is to do something like this

let connection = new HubConnectionBuilder()
  .withUrl('url1', {transport: HttpTransportType.WebSockets})
  .build();
connection
  .start()
  .catch(reason => {
    if(reason === 'WebSocket not supported') {
      connection = new HubConnectionBuilder()
        .withUrl('url2')
        .build();
      connection.start();
  }
});

An issue though is that I haven’t found a reliable way to identify if the connection failed because WebSocket wasn’t supported, is this possible?

Are there any better ways to do this?

Edit:
Was able to find the error message by looking through the source code. Would there be any issues with doing something like this?

let connection = new HubConnectionBuilder()
  .withUrl('url1', {transport: HttpTransportType.WebSockets})
  .build();
connection
  .start()
  .catch(err => {
    if((err instanceof UnsupportedTransportError && err.transport === HttpTransportType.WebSockets) || 
   (err instanceof AggregateErrors && 
   err.innerErrors.some(ie => ie instanceof UnsupportedTransportError && ie.transport === HttpTransportType.WebSockets))) {
      connection = new HubConnectionBuilder()
        .withUrl('url2')
        .build();
      connection.start();
  }
});