PHP + ? Динамическое обновление контента

Я как человек, постоянно следящий за трендами мира веб-разработки скажу, что частенько вижу как между пхп бекендом и браузером делают WebSocket сервер на NodeJS, Express/Koa + SockJS

Читай про Single Page Application, Data Binding Frameworks\Libraries (Angular, Knockout etc.) и WebSocket

Протокол WS очень мощный, но считай всю структуру надо будет переписывать, зачем все эти

NodeJS, Express/Koa + SockJS

нужны? чем ws под управлением js плох? интерактивности не вывозит?

AJAX это какой-то 20 век

серьезно? - вот это новость! ...

а вебсокеты это надо понимать светлое будущее? вебсокеты это тот-же пуллинг, завернутый фантиком, и нагрузки в этом случае только возрастают на сервере.

event-drive спасет демократию

event-driven

В треде про динамику.

man event

10 секунд не создадут нагрузки на сервер. Сделай флаг на сервере и проверяй его.

Юзай ws, Redis. Можно в редис подписаться на канал, либо опрашивать постоянно нужные ключи. Появившийся ключ тут же пушится в ws, у клиента срабатывает колбэк -> появляется мессага. Это не 5 - 10 секунд, это моментально. Либо с подпиской, с ней не придётся опрашивать.

Если нет желания писать свои очереди на Redis, то можно заюзать что нибудь из готового. Есть как сервисы специальные так и ПО типа RabbitMQ.

Делать постоянный опрос в мускуле лучше не стоит, лучше забудь об этом.

Когда онлайн 700 человек - создадут.

Если не хочешь обмазываться NodeJS, то ReactPHP + WebSockets.

Дану? А мне казалось, что это такие обычные сокеты, ну знаешь те самые, которые используются например в игорях?

ReactPHP

Это в котором даже $_POST не работает?

и вот зачем тащить жабаскрипты на сервер? когда есть нормальные языки.

Давай примеры

ну шо как маленькие. python/go

речь идет о PHP

70 get в секунду к статическому флагу на nginx????? Да ладно!

разве в игорях что-то особенное для веб?

Как сделать чтобы это не давало сильных нагрузок на сервер?

не трогать БД без особой необходимости, для начала

вебсокеты это тот-же пуллинг

Вон из профессии.

не стоит так самокритично

а что в пхп с вебсокетами не так?

проще взять rabbitmq, там есть готовый плагин для работы с вебсокетами, а обновления отсылать в момент записи в базу, впрочем, так же можно использовать пабсаб из redis, как уже было сказано.

А чем JavaScript плох?

пропустил var в недрах масштабного проекта - потерял неделю на отладку

Например тем, что из-за прототипного ООП api всех библиотек основаны на тотальных вездесущих коллбэках и замыканиях, что превращает весь код в нечитабельную лапшу, сложность и запутанность которой растет экспоненциально. Реализация модульности через создание и вызов анонимной функции, как и триллион подобных извращений. Нестрогая динамическая типизация, которая делает архитектуру неинверсируемой-асбтрагируемой (в контектсе IoC), нетестируемой (из-за невозможности создания изоляционных фреймворков), в целом абсолютно непредсказуемой при изменении отдельных частей; из динамической типизации, и, в целом самого прототипного ООП, невозможность статического анализа кода, из-за чего код на жабаскрипте невозможно ни рефакторить, ни нормально поддерживать вообще ничего. Причем нестрогость на жс доведена до такого абсурда, если хотя бы в таких языках как питон или руби, я получу иксключение хотя бы рантайме при опечатке, забывании передачи параметров и т.д, в жс не будет ровным счетом ничего, типа как оратор выше сказал про то, что можно забыть поставить var и неделю дебажить. К тому же, я еще забыл рассказать, что дебажить жс сущий ад.

Да, JavaScript не для масштабных проектов, там рулить Java и .NET
Но вот если нужно сделать микросервис, какую-нибудь APIшку - то нода рулит

линтеры решат эти проблемы

выводить новую запись из БД сразу после её появления

websocket, всегда так делаю.

пропустил var в недрах масштабного проекта

Этого не может быть. Есть strict-семантика, есть линтеры, есть кодревью и тесты.

Если _всего_ этого нет, будет плох любой язык и платформа.

ASP.NET Core WebApi элементарно покрывается тестами. От ноды кровью захаркаешься, когда начнешь тестировать и ловить рандомные баги там, где бы их никогда не было. Микро не значит «маленький - мало кода», мироксервисы еще могут объединяется в децентрализованные распределенные кластеры, что, например, позволяет делать Akka.NET. В общем, не вижу смысла использовать жс там, где его можно не использовать.

JavaScript хорошо тем, что заставляет думать
Из всего поддержу только проблему дебага
Для статики и рефакторинга есть TypeScript и прочий Flow
Есть одна фраза, описывающая всю суть джаваскрипта: «Каждый дрочить как хочет»
Это как главный плюс, так и минус
JS хоть и стоит в одном ряду с PHP и e.t.c, он совсем другой
Тут даже нет стандартной библиотеке
Ну а тестирование - есть же Karma, свои задачи вроде решает

Плюсую! Привыкли уже, что IDE сама все подставляет

Потерял ссылку на статью, где описано, как правильно использовать блоки try/catch для отлова багов, но легко гуглится
Проблема объедения сервисов то в чем выражается? Есть API, один сервис делает запрос другому и все

Кодеревью помогают только найти ошибки, которые автор кода сам не увидел (когда глаза замыливаются). Стрикт-семантика в целом бесполезная чуть более, чем полностью. От такого извращения, как JSLint хочется блевать моментально. Решили для простоты создать динамический язык с автоматическим преобразованием и конвертацией типов, для чего нужен очень жирный, сложный, рантайм. Но для того, чтобы быть уверенным во всем этом, создается какой-никакой ... анализатор! Анализатор, Карл! Т.е. язык некомпилируемый, но его немножко все-таки надо компилировать, чтобы избежать ошибок.

Интересно, когда я нажимаю кнопочку во вьюхе, а отлаживая контроллер просто смотрю, что мне приходит какой нибудь null, вместо десериализированного объекта. В чем именно в таком случае заключается процесс «думанья»? Программирование на js мне напоминает ситуацию, если бы слепому надо было бы передать конверт глухому и оповестить глухого, что ему этот конверт передали.

Для статики и рефакторинга есть TypeScript и прочий Flow

Сразу видно человека, никогда не писавшего на TypeScript. Да, в тайскрипте семантика объектов описывается через классы, модификаторы доступа, есть неймспейсы, интерфейсы, генерики, строгая типизация и автоматический вывод типов, аттрибуты. Это не отменяет того факта, что жс это сущий ад.

О, оказывается баги можно чинить через try-catch. Прям сейчас пойду и обверну все наши проект в один большой глобальный try-catch. То-то мы раньше не знали, что так можно.

1. Пришел null - посмотри в консоль. Ну и такие вещи должны сначала тесты проходить. Если тест не пройден, то смотри логи.
2. Почему не писал? Ты писал, что сложно разбираться в коде, где динамика - я тебе предложил TypeScript и Flow

жс это сущий ад

Очень необоснованное заявление

Ловить и чинить разные вещи
Если у тебя код выполняется, ничего не выплевывая - это очень грустно
Есть try/catch, который позволяет отлавливать баги

Он там не работает по понятным причинам, а если они тебе не понятны, но не пользуйся. Для доступа к данным запроса там есть другие методы.

Нет. Я имел ввиду, что WS - это почти те же самые TCP/UDP сокеты, просто с сахарочком.

try/catch не отлавливает баги. Он перехватывает исключения, но в дебаге это абсолютно никак не поможет.

Какой сейчас самый лучший инструмент для динамического обновления?

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_ser...

Как сделать чтобы это не давало сильных нагрузок на сервер?

Использовать memcache или редиску.

Это в котором даже $_POST не работает?

Там и $_GET не работает, там этого вообще нет, а есть Request и события. Внезапно, да?

Ну я это и имел ввиду

Не знаю что вы хотите мне доказать. Нравится или нет, все перечисленное помогает мне в работе (пропущенные var в коде - у меня такого не бывает), JS мне очень нравится.

наверное, у нас разные представления о масштабности, я лишь делюсь опытом

Если основное приложение перепиливать на всякое модно-молодёжное не хочется то думаю можно как-то так:
На клиенте лонг-пулинг или вебсокеты (посмотри что будет лучше работать, по логике ws должны быть лучше, но логика и web не дружат) опрашивающий отдельный нанодемон который только и делает что поддерживает 100500 клиентский конектов, получает события от основного бекенда, и засовывает их в клиентские коннекты. При-чём такой демон можно реализовать в общем виде, без привязки к конкретному проекту, а значит вполне вероятно что он уже кем-то реализован.
Но это так, рассуждения с дивана.

когда только подымалась шумиха вокруг вебсокетов, что-то для php пилил один из тогдашних девелоперов хабры - КакСерпомПоЯйцам и писал об этом на самой хабре. вроде, разработка называлась phpdaemon, а ник его на гитхабе - каксерпом. не вижу причин не использовать достижения последних версий пхпстроения, но если хочется ковырнуть:

http://daemon.io/
https://github.com/kakserpom/phpdaemon

повторюсь: обычно вебсокет-шина по сути своей является отдельным микросервисом и слабо связанна с бекендом, нет ни одной причины смешивать ее с регулярны хттп приложением и запускать одной коммандой, это все-равно будет композиция разных сущностей. лучший выход - использовать готовое решение, когда воркераунд для вебсокетов описывать не нужно вообще, например, плагин из rabbitmq о котором я писал выше или pubsub из redis в связке с sockjs (с последним больше забот).

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

все сводится к тому, что в момент изменения сущности следует слать обновления в трубу, это один basic_publish(data), а трепа уже...