PUSH-уведомления НА сервер. Это возможно?
 

Многие знают, что такое PUSH-уведомления в интернет-браузере. Работу обеспечивает Гугловский механизм Firebase Cloud Messaging. А можно ли сделать PUSH-уведомления не в браузер, а на сервер? Речь, конечно, не о "всплывающих окошках" на сервере, а о неком программном триггере, который должен реагировать на PUSH и запускать какой-то PHP-скрипт.
Другими словами, есть мой сервер, который должен оповещать другие (чужие) сервера. Как это реализовать?

Создавать на чужих серверах web-хуки или делать циклический HTTP-опрос с чужих серверов на мой сервер - плохой вариант.
Есть нюансы:
1. Заранее неизвестен список чужих серверов (они должны как и браузер "подписаться" на PUSH)
2. чужой сервер может находиться внутри локальной сети предприятия и недоступен из мира (но может обращаться в мир)

Не смог найти детальное описание, как работает механизм PUSH в клиентской части - в браузере. Можно было бы попробовать написать аналог для сервера...

Да, эта технология уже известна и работает. Пробовал на PHP-библиотеке SWOOLE - как-то громоздко. Потом написал приложение на Node.JS - работает, но раз в 3 месяца подвисает (и требует открытия портов, которые в сети предприятия могут быть закрыты).
В общем, сейчас думаю про PUSH.

P.S. подозреваю, что Firebase Cloud Messaging тоже работает на сокетах, но информация о протоколе и серверах скрыта.

Я придумал гениальную схему ;). Она безумна, но... это работает!
Можно передать PUSH-уведомление с сервера mysite.com на сервер example.com, который находится в интрасети предприятия и доступ из мира к нему закрыт.
Для этого на компьютере администратора сервера запускаем браузер, который подписываем на PUSH-уведомления с сервера mysite,com
Браузер служит посредником. Таким образом, как только сервер mysite,com отправит пуш, так на сервере example.com сработает необходимый PHP-скрипт.

<?php
// receivepush.php
header('Access-Control-Allow-Origin: *'); // указывает браузеру разрешить запросы из любых источников

// здесь выполняется полезная работа (сохранение в базе и т.п.)

echo '{"answer":"processed"}'; // ответ в браузер на пуш
?>

// инициализация Firebase Cloud Messaging client как описано здесь:
// [url]https://firebase.google.com/docs/cloud-messaging/js/client?authuser=0[/url]
// ...
// ...
var messaging = firebase.messaging();


messaging.onMessage(
 function(payload)
 {
 console.log('onMessage:', payload);


// отправка POST-запроса на сервер:
// пример взят отсюда: [url]https://developer.mozilla.org/ru/docs/Web/API/Fetch_API/Using_Fetch#Тело[/url]
const url = 'https://example.com/receivepush.php';

async function postData(url = '', data = {}) 
{
const response = await fetch(url, 
  {
  method: 'POST',
  mode: 'cors',
  cache: 'no-cache',
  credentials: 'same-origin',
  headers: 
    {
    'Content-Type': 'application/x-www-form-urlencoded' // для обычного POST-запроса
    },
    redirect: 'follow',
    referrerPolicy: 'no-referrer',
   body:data
  });
  return await response.json();
}

postData(url, 'cmd=1&mydata=12345')  // какие-то мои данные (они будут получены из пуша)
 .then((data) => 
  {
  console.log('принят ответ');
  console.log(data);
  });

}
);

// если вкладка браузера закрыта, то обработчик пуша должен быть определен в service worker:
messaging.setBackgroundMessageHandler
(
// аналогично messaging.onMessage()
);

с таким же успехом можно подключиться напрямую к серверу по websocket с компьютера администратора )

Можно. А смысл? Вебсокетный слушатель на сервере - это не совсем тривиальная задача. К тому же придется открывать нестандартные порты. И про какой Вы говорите сервер: mysite.com или example.com? Если про mysite.com, то его еще и предстоит хорошо защищать от атак по вебсокету. А так Гугл шлет пуши на компьютер и это не нервирует mysite.com; а example.com в локальной сети работает по обычному https на 80-м порту.
И ещё: вкладка в браузере рано или поздно "заснет" (будет выгружена из памяти). Это значит вебсокетное соединение перестанет работать. Пуши при этом сработают.