How to implement passive messenger architecture?

Question

Software design

The messenger needs to be done on web sockets, this is understandable. You can throw someone when they started writing, sent / delivered and other amenities of realtime
To save RAM, it was decided to close the websocket connection when exiting the dialog and switch to push notifications. BUT push notifications on the client device can be banned (both on mobile phones and on the web version).
For good reason, the person went to another section, and when he received a message, he should find out about it. As I wrote above, the websocket closes outside the dialog
1) If pushes are disabled on the client, are those that are not visual banned? i.e. pushes are needed not those that come to the switched off phone, but those that will be with the application open (all of a sudden these are different things and I'm looking for crutches in vain)
2) As an option there was a long pool, but I'm worried about resources
3) requesting the server every N seconds is a terrible option

Answer 1

read about long polling requests, for example here and here , and I would look more at the comments in the first article.

Answer 2

In my opinion, you refused the long poll in vain, with the correct organization of the backend, the open long poll practically does not eat server resources.
here the key question is who on your back answers requests.