6

I've created a rest generic service which additionally consume a websocket per resource my websocket code looks like so:

initialize(hubSubRoute: string): void{
    const accessToken = this.authManager.getRawAccessToken();

    let hubUrl = environment.baseUrl + hubSubRoute;
    if (accessToken) {
        hubUrl += '?' + this.hubAuthorizationQueryParameter +'=' + accessToken;
    }

    this._hubConnection = new HubConnectionBuilder()
                                .withUrl(hubUrl)
                                .build();
}

startConnection(): void {

    this._hubConnection.start()
        .then(() => {
            console.log('Hub connection started');
            this.connectionEstablished.emit(true);
        })
        .catch(err => {
            console.log('Error while establishing connection');
        });
}

I know web-sockets are long lived connection. I'm wondering the best practices for maintaining their longevity. For example I have a messages services. Which will open a websocket and post message as they come, in, However,

If the user navigates away from that conversation, should I leave the web-socket open?

Or Should I close it and when the user returns back to that conversation, just obtain the missing messages and reinitialize the web-socket?

  • Why can't you multiplex multiple resources over the same Connection? – Deduplicator Jun 29 '18 at 13:39
  • @Deduplicator, I probably could, but when I designed this It was a lot easier designing the archiecture generically this way because it plugs right into my crud services. I'm 50/50 on redesigning my architecture to use a single hub. I'd just need to register a type based map to filter my connection, and when to send, but then my methods would be have to be weakly typed – johnny 5 Jun 29 '18 at 14:35
  • FWIW the Phoenix framework will time out and close a socket after 60 seconds without getting a message from the client. – RubberDuck Jun 29 '18 at 21:59
3

Creating a new connection is expensive in terms of resources. The goal of WebSocket is specifically to avoid creating connections on regular intervals, such as in the case of long polling.

However, maintaining an open connection is also expensive: if you have too many of them, you may not be able to open new ones (without additional network hardware, etc.)

Therefore:

  • If you're pretty sure the use won't be interested by the events for a long time, close the connection.

  • If you're running out of connections, close the ones which are inactive.

  • In other cases, just keep it open, which would also make your code simpler.

  • Thanks that answer my question, but Currently I’m hooking into an event on my server to push notifications on create,update and delete. I’m using a socket per resource. The main reason I designed it that way was it was easy to make generically, I’m not sure if I should switch my architecture to use a single socket, what would you recommend? – johnny 5 Jun 29 '18 at 12:39
  • 1
    I would try to limit yourself to one socket per client if you can. Because the connection remains open, a single server can handle less concurrent clients than http long polling. – RubberDuck Jun 30 '18 at 11:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.