skip to Main Content

I have a node.js app running in Azure as a webApp. On startup it connects to an external service using a websocket subscription. Specifically I’m using the reconnecting-websockets NPM package to wrap it to handle disconnects.

The problem I am having is that because there are 2 instances of the app running on Azure (horizontal scaling for failover) I end up with two subscriptions at any one time.

Is there an obvious way to solve this problem?

For extra context, this is a problem for 2 reasons:

  1. I pay for each message received and am over quota

  2. When messages are received I process then and do database updates, these are also being duplicated.

2

Answers


  1. If you don’t want your subscription to be duplicated then it stands to reason that you only want one process subscribing to the external websocket connection.

    Since you mentioned that messages received will be updated in the db, then it makes sense that this would be an isolated backend process since you made it clear that you have multiple instances running for the frontend server (and whether or not a separate backend).

    Of course if you want more redundancy, you could use a load balancer with simple distribution of messages to any number of instances behind. Perhaps some persistent queueing system if you feel that it’s needed.

    If you want these messages to be propagated to the client (not clear from the question), this will be a bit more annoying. If it’s a one-way simple channel, then you could consider using SSE which is a rather simple protocol. If it’s bilateral then I would myself probably consider running a STOMP server with intermediary broker (like RabbitMq) and connect directly from the client (i.e. the browser, not the server generating the frontend) to the service.

    Not sure if you’re well versed with Java, but I made some app that you could use for reference in case interested when we had to prepare some internal demos: https://github.com/kimgysen/zwoop-backend/tree/develop/stomp-api/src/main/java/be/zwoop

    For all intents and purposes, I’m not sure if all this is worth the hustle for you, it sounds like you’re on a tight budget and that you’re looking for simple solutions without too much complexity. Have you considered giving up on load balancing the website (is the load really that high?), I don’t have enough background knowledge on your project to judge, I believe. But proper caching optimization and initially scaling vertically may be sufficient at the start (?).
    Personally I would start simple and gradually increase complexity when needed.

    I’m just throwing ideas at you, hopefully it is helpful in any way to have a few considerations.
    Btw, I don’t understand why other answers on this question were all deleted (?).

    Login or Signup to reply.
  2. You basically want to have an AppService with potentially multiple instances, but you don’t want your application to run in parallel. At least you don’t want two have two subscriptions. Ideally you don’t want to touch your application code.

    An easy way to implement this would be to wrap your application into a continuous WebJob, and set its scale property to singleton.

    Here is one tutorial on how to set up a nodejs webjob: https://morshemesh.medium.com/continuous-deployment-of-web-jobs-with-node-js-2308f95e63b1

    You can then use a settings.job file to control that your webjob only runs on a single instance at any one time. Or you can use the Azure Portal to set the value when you manually deploy the Webjob.

    {
      "is_singleton": true
    }
    

    https://github.com/projectkudu/kudu/wiki/WebJobs-API#set-a-continuous-job-as-singleton

    PS: Don’t forget to enable Always On. It is also mentioned in the docs. But you probably already need that for your current deployment.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search