I have a react web app which generates solutions for rubik's cubes. When the user makes a query on my site, it starts a long computation process (anywhere from 1 second - 240 seconds). Every time a solution is found, the state is changed and the user can see the new solution.

However, this app often crashes on mobile for large queries, I believe the browser is demanding too much memory and kills my page. Because of this, I want to add a node.js backend to handle the computation.

I would like for the following functionality:

1. When the user makes a query request, it sends that to the backend which can start computing. Every so often, the frontend can update to show the current tally of solutions.
2. If the user prematurely wants to cancel the process, they can do so, also killing the backend thread.

How can I set this up? I know I can very easily make HTTP requests to my backend and receive a response when it is done. However, I'm not sure how to accomplish the dynamic updating as well as how to cancel a running thread. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.

I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.

Any help is appreciated!

CodePudding user response：

However, I'm not sure how to accomplish the dynamic updating. I have heard of long polling but I'm not sure if this is the right tool for the job, or if there is a better method.

Three main options:

1. A webSocket or socket.io connection from client to server and the server can then send updates.

2. Server-send events (another way for the server to send updates to the client)

3. Client polls the http server on some time interval to get a regular progress report.

as well as how to cancel a running thread

If by "thread" here, you mean a WorkerThread in nodejs, then there are a couple of options:

1. From your main nodejs process, you can send the thread a message tell it to exit. You would have to program whatever processing you're doing in the thread to be able to respond to incoming messagessto that it will receive that message from the parent and be able to act on it. A solution like this allows for an orderly shut-down by the thread (it can release any resources it may have opened).

2. You can call worker.terminate() from the parent to proactively just kill the thread.

Either of these options can be triggered by the client sending a particular http request to your server that identifies some sort of ID so the server's main thread can tell which workerThread it should stop.

I would also like this app to support multiple people trying to use it at the same time, and I'm not sure if I need to consider that in the equation as well.

This means you'll have to program your nodejs server such that each one of these client/thread combinations has some sort of ID such that you can associate one with the other and can have more than one pair in operation at once.