How would you make a react application check at a certain interval if the backend has been restored?

Question

React

there is a request for backing -> an error has occurred -> the user has been notified.
Next, we want the application to check at a certain interval whether the work of the backend has been restored.
How would you implement?

Answer 1

The global state is offline and swotting at the healthcheck address, how else?)

Answer 2

Well, if an error occurs, then we take and throw a request for a back with any interval, until we get through))

Answer 3

We did this through redux saga, they even have an example in the documentation with a timer: https://redux-saga.js.org/docs/advanced/Channels

Answer 4

It can be important to distinguish what exactly happened - a problem with the Internet, a problem with the backend, or a problem with the client side. Those. first you need to try to determine exactly this.
- if the backend returned an error, then the problem is not in the network
- to cover a number of problems with the client - you can drag the application version identifier in each request and response so that the server can log inconsistencies (for example, problems with caching frontend code files, if links to it are incorrectly organized , i.e. without a hash in the name for example)
- the client itself can generate errors according to its own logic (if javascript or analogues are used), the main thing is to inform the server about this (developers should be aware of problems immediately, and not wait for clients to call them)
For each reason, an appropriate response may be required. A good method is to be able to repeat the erroneous operation, and if it is critical to duplication (so as not to create a duplicate of new posts on the forum, for example), add a unique identifier created for the action in the message itself. You don't need to ask the user to resend in the interface, it's ugly, it's better to report in the float box that there were errors and resending, with statistics, 'how many attempts' and a 'stop' button. Moreover, the client must distinguish between logical errors (for example, there was an error in the code and the old version of the frontend is trying to send an already incorrect message format to the backend, and he swears at this, repeating the action is not required, but suggesting solutions - yes)
Problems with version incompatibility are generally a classic, when a developer is too lazy to support two migrations at once (it really doesn’t just happen), but they can come out very suddenly, and it’s very important to report this in the logs, especially when live updates are often practiced.
For this reason, it is better to move the error logging system from the frontend away from the main code and backend logic (up to other physical hardware), you can also throw errors and backend there