Сергей Протько

private _http: Http;

constructor(http: Http) {
    this._http = http;
}

Подход - Inversion of Control и Dependency Injection как реализация подхода

Как работает ассайн пропертей из конструктора и почему так делать удобнее: https://www.stevefenton.co.uk/2013/04/stop-manuall...

www.martinfowler.com/eaaCatalog/rowDataGateway.html

затем же зачем в erlang нужны микропотоки и в golang горутины.

Ведь js же может по идее подхватить название вызываемого метода и сделать внутри ajax запрос

И да и нет: https://developer.mozilla.org/en-US/docs/Web/JavaS...

В целом я конечно одобряю здоровую лень, но вот это уже нездоровая лень. Во Первых потому что restful api это не RPC (хотя любое RPC можно организовать как restful api). Во вторых, будет сложнее обрабатывать ошибки. В третьих напишите под вашу апишку такой вот клиент и используйте, спрятав все нюансы работы с http внутрь.

php.net/manual/en/book.dom.php

потому что у web сервера (nginx/apache) есть свои таймауты. Для вашей задачи вооружитесь очередями (beanstalkd, gearman, etc).

composer для того чтобы обновлять "ядро" (со своим приватным репозиторием возможно). "автоматизировать" - различные штуки от обычного bash скрипта до инструментов аля ansible. А еще docker клевая тема для подобных вещей. Если "это работает в контейнере то скорее всего будет работать на любом другом сервере".

Как правильно

Не делать этого. Если вы указываете время в UTC и потом добавляете часовой пояс - все уже будет учитываться за вас.

отправить ответ (echo 'Ответ';) на другой порт получателю, а не тот от которого пришел запрос.

для этого между сервером и клиентом должно быть установлено соединение. Так работает TCP. Причем сервер не может выступать инициатором.

А если у вас есть два соединения между клиентом и сервером - то никаких проблем.

промисы.

Учите регулярные выражения.

p.s. А еще лучше - возьмите готовый компонент для маршрутизации.

Но перед записью эти данные нужно обработать

не нужно. Вот вам и решение проблемы. prepared statements для sql и экранирование при выводе.

1. Поскольку я сомневаюсь что вы написали свое приложение на reactphp (ну то есть это не то же приложение что сокеты слушает), то вам нужно будет организовать общение этих процессов. Тут подойдет какая-нибудь штука вроде zeromq.

В этом случае мы можем по какому-то событию в одном процессе, формировать сообщение и кидать его через pub/sub другому процессу. Другой процесс принимает сообщение и делает то что нужно, то есть находит нужного пользователя в массиве и кидает ему событие.

2. тут зависит от того, хотите ли вы сразу обработать что-то или хотите что бы это что-то происходило изолированно в другом процессе (предпочтительно с точки зрения надежности и стабильности). В первом варианте вам нужно что-то вроде роутера. Во втором - обратное первому.

p.s. Я не рекомендую вам связываться с websockets на php, проще развернуть примитивный сервер на socket-io и через тот же zeromq передавать нужные сообщения между node и php. Проблем меньше будет как для клиента (socket-io намного проще с точки зрения клиента) так и сервера (socket-io намного более надежное решение).

Не мне судить о самом подходе, так что остановлюсь лишь на предложения об оптимизации ваших процессов.

Что можно сделать - так это автоматизировать процесс формирования миграций между версиями. Например через apgdiff.

Мол идея такая. У вас и так организовано все так как вам удобно. Потому мы можем просто написать простенький скриптик который заливает новую схему, и потом генерит миграцию на основании различий между предыдущей версией. Это позволит вам уменьшить количество рутины.