Push server, server side, php+node.js, how to implement it correctly?

Question

css

the task is how to build your own push notification server, the site is written in php, some of the subscribers will receive unique push messages, as well as mass notifications (for example, notifying all subscribers, let's take the number of 100K subscribers). After searching for options, I decided to use node.js + web-push , exchange with php through redis (user ids, messages from the site).
The following points are of interest:
1) Is a queue server necessary for such a large number of messages or node.js can handle it, how to implement it correctly so that the server does not crash.
2) how to properly organize the transfer of user ids and a message when personal notifications are a small amount of data, and whether redis can handle 100K or use mongodb to store users and message queues on the node and simply synchronize them with the site database, or is it better to use other methods passing data between node.js and php and storing and processing a large number of notifications.
3) is it worth linking the browser subscription with the user id on the site in order to send him offline personal or personal push notifications only when the user is online?
4) maybe I didn’t understand / came up with an algorithm for push notifications at all, maybe then tell me how to do it right
ps third-party resources are not interesting for this, I will implement the server in order to study node.js and push for further use in projects

Answer 1

Don't forget to check the order of including js files!!!)
(As requested)

Answer 2

First, you need to understand exactly how push notifications work.
Second, it is unnecessary to generate extra components.
There are solutions for PHP too https://packagist.org/packages/minishlink/web-push
First you need to understand that browser subscriptions need to be stored in a separate table or collection depending on your main storage.
For private messages, you will need to implement an optional but enabled connection by default. It should be remembered that the same user can log in from different devices. For example, from a desktop, laptop and tablet. One user can have multiple subscriptions.
You will need a queue server such as RabbitMQ. You will have 2 types of tasks - public and private.
A public task is a broadcast task that aims to reach all users.
For example, when new material is published on the site and the site is ready to accept everyone.
It will require a simple queue . The task of the worker will be to find all subscribers, create a task for each of them and put this task in the second queue with many workers who will directly send pushes.
The first task will contain the id - material.
The second will contain the id of the material and the id of the subscription.
This approach will allow the queue to work very quickly. Plus, selecting from the database by id is almost instantaneous, regardless of the engine + it is perfectly cached at the level of the database itself. It is necessary to get from basis only a necessary minimum of fields.
Distribution of private messages can be done on the basis of the second queue, supplementing the task with several fields. Those. workers will not care what they deliver.
Recording a job with all fields for global publications is not a good idea, because this will take up a lot of memory and cause brakes. Plus, this solution doesn't scale very well.
Workers can be made in Node.js, or in PHP. RabbitMQ has everything you need for this. You can look for other queues, but RabbitMQ is a fairly popular and proven solution.