Pull to refresh

Comments 27

Я делал иначе:
1) есть команда создания соединения, она поднимает само соединение и отправляет на роутер.
2) Внутри роутера валидируется реквест и формат сообщения (в моём случае jsonrpc)
3) Далее реквест отправляется в нужный контроллер, в зависимости от поля «method» в jsonrpc.
4) При наличии ошибок или ответа из контроллера — можно сопоставлять «id» сообщений для псевдосинхронного выполнения (опять же кусок jsonrpc стандарта)

Плюс с помощью DI в контроллеры подсовываются пул соединений, таймеры и прочие хелперы.

Т.е. в моём случае контроллеры выполняют действия на запросы клиента (в т.ч. могут инициировать свои), а модели являются некими сущностями, изолированными от респонза. Вроде это в MVC называется «пассивная модель».
Вроде это в MVC называется «пассивная модель».


в MVC это называется отсутствие MVC, то есть у вас нет отделения UI от логики обработки данных, а в этом вся суть MVC. Вы же наверное имели в виду анемичную модель предметной области.
Почему же нет отделения? Обычная классическая MVC модель из Laravel или Symfony, но переведённая в немного другую стезю. Вместо http — jsonrpc, плюс асинхронная работа.

Фиг знает, правильно ли это в связи с вебсокетами, но в моём случае контроллер из статьи является альтернативой обычному веб-серверу.
Обычная классическая MVC модель из Laravel или Symfony


классический MVC имеет смысл на клиенте, где у нас контекст приложение живет дольше чем один запрос.

image

А в Laravel и Symfony классический MVA

image

Роль адаптера выполняют GRASP-контроллеры.

Самое важное — и в том и в другом варианте контроллеры отвечают только за первоначальную пред-обработку данных для последующей передачи в модель. А уже в модели будут происходить манипуляции с данными связанные с логикой приложения.

Что до websockets — опять же никакой разницы, так как мы всеравно будем асинхронные действия пользователя ловить в контроллере и просить приложение что-то сделать.

Хотя опять же ничего плохого в толстых контроллерах и тонкой модели нет, иногда это удобно.
Отлично, ставлю плюс.

Тоже пилю небольшой амбициозный проект, но там правда API буду использовать не для фронтенда, а для мобильных приложений. Тоже в своё время малость игрался с настройкой nginx, так как нужно было разделить по поддоменам основной сайт и его api.
Я рекомендую вам не делать ссылки на главной туда, куда у пользователя нет доступа (просмотр гостем примеров других в главном списке)
Очень интересно почитать про разработку Frontend и Backend. Ради любопытства решил небольшой проектец сделать — рейтинг игроков по настольной игре. То есть ничего сложного, в принципе. А в Yii насмерть, оказывается, зашит Boostrap. Хочется как-то использовать тот же Angular UI, а колхозить с самого начала не хочется.
Так используйте Yii в качестве REST сервера, тогда вам будет совсем не важно какой frontend использовать.
И готовить страницу на клиенте полностью? С REST придется возиться со всякими индексациями поисковиками как раз. И я как-то пока не очень верю в SEO-безоблачность такого подхода.

С другой стороны, не очень хочется на столько глубоко разделять технологии fronend и backend. У меня же не HighLoad предполагается.

Хотя за мысль все равно спасибо. Может в конечном итоге использую как раз такой вариант. Я просто по началу посмотрел как Yii генерит поля для формы в шаблонах. Подумал, что здорово было бы также сгенерировать некий интерфейс на frontend, но только с Angular UI. А для этого, похоже, немало усилий нужно приложить.
Если думать о мобильных приложениях, да и любых других клиентах, то REST подход подходящий. Думаете использовать AngularJS — у него как раз все под это заточено — $resource, $http. Нужнен будет в любом случае сервер, отдающий данные.
В целом да, нужно разбираться в новой парадигме так или иначе. Жду вашу статью. Хочется увидеть полный кейс у того, что уже умеет это готовить.
>в Yii насмерть, оказывается, зашит Boostrap
это не так, вы можете использовать бутстрап, можете не использовать. Boostrap используется в утилитах yii, и в некоторых виджетах.
Чуть выше написал про некоторое любопытство к генерации форм. Но в целом понятно, что можно прописать вручную все нужные интерфейсы хоть c Angular, хоть с jQuery. Но там видимо придется еще и за форматом передаваемых данных следить внимательно.
А так же можно тащить пакеты из bower/npm через composer. Либо отдельно поставить npm, немного инфы тут
> if ( $http_user_agent ~* (...) ){
> rewrite ^ /snapshot${uri};
> }
Очень похоже на cloaking. Google за такое по рукам не бьет?

UPD: А, не, отдаются ведь снепшоты тех же страниц, тогда все ок
Так же в случае падения надо перезапустить данный процесс. Не нашёл решение более элегантного, как через каждую минуту запускать команду в crontab
Supervisor: A Process Control System
Создание снапшотов хорошо работает, если у вас небольшой сайт. А если у вас на сайте тысячи страниц, генерируемых и обновляемых пользователями?
Немного погуглив, нашел информацию о ?_escaped_fragment


_escaped_fragment является устаревшей рекомендацией с октября 2015-ого года. В целом лучше использовать html5mode в роутинге, ну а на сервере генерить снэпшеты как генерили.

Ну и да, это автоматически решает проблемы с ботами соц сетей и т.д.

обновление sitemap с интервалом 10 минут, используя crontab


ну так себе решение на самом деле, было бы интереснее очереди сообщений и обновление по требованию или грамотная инвалидация кэша…

но готовое решение быстро нашлось — socketo.me.


опять же, ratchet это прикольно но он довольно давно не обновляется. Есть более качественные реализации WS серверов. Отдельно стоит заметить проект amphp и тамошнюю реализацию HTTP/WS сервера aerys

Ну и там же в amphp есть асинхронные драйвера для работы с mysql или postgres, что круто в условия event loop. В вашем же случае ORM хоть работает и быстро, но на это время блокируется весь сервер. Что не ок.

Не нашёл решение более элегантного, как через каждую минуту запускать команду в crontab


supervisord
Спасибо за замечания, обязательно учту.
Возник вопрос — я использую html5mode. У меня есть страница, которая открывается по адресу example.com/news/22
Ну а как мне понять что отдавать — статику или динамику? Можно пример конфигурации?
по юзерагенту, примерно так же как как у вас со снэпшотами сделано. Просто чуть больше юзер агентов надо добавить. В остальных случаях при отсутствии файла. к которому мы обращаемся, отдавать index.html.

Из вариантов посложнее и интереснее — серверный пререндер (для React, Angualr2, Ember и других штук поддерживающих server-side рендринг), который чаще используется для улучшения UX, но и для поисковиков норм. В этом случае алгоритм будет одинаков для всех. Засылаем запрос в express-сервер какой-нибудь, тот запускает рендринг первоначальный приложения и выплевывает на клиент. Когда подтягиваются JS либы приложение оживает, но пользователь уже видит в принципе оное с каким-то состоянием, что собственно и улучшает UX.

Конечно же этот подход намного сложнее так как вводит ограничения на то, что мы можем делать и как примерно все это должно работать (например stateless UI, проход данных сверху вних и т.д. при таком варианте все это можно организовать относительно малой кровью).
это более серьезное решение

Это очень субъективная оценка.

К сожалению найти толковых разработчиков которые не испортят все на ноде — это еще поискать надо. Их даже меньше, чем адекватных PHP разработчиков. По поводу react vs angular — тут опять же, зависит от задачи. Если надо быстро и изоморфно — angular2 проще, поскольку фреймворк предоставляет готовую инфраструктуру. С реактом придется все это собирать (хотя это не сильно сложнее на самом деле). В целом же опять же все упирается в адекватных разработчиков, а адекватные разработчики сделают нормально в любом случае.

phalcon же несет в разы больше рисков чем node.js или php. Сегодня вы счастливы а завтра ищите сишников, или php-ников которые нормально владеют gdb + strace
да не, все гораздо проще ))
React потому, что возможностей больше
phalcon потому, что быстрее и меньше кушает. Там уже давно все ровно и поиски сишников не нужны ). Глянул код на зефирке, который не сильно отличается от пэхапэ и все стало ясно.
Ну, а nodejs потому, что она быстрее пэхапэ )

А вот прямота рук влияет на любой инструмент, это отдельная тема )
Скорость ноды — довольно субъективная оценка, т.к. php 7 показывает результаты превышающие аналогичные нодовские. С другой стороны на ноде проще (т.е. это не значит, что и на пыхе нельзя) параллелить операции, за счёт чего можно получить неплохой такой профит. В любом случае по количеству сжираемой оперативной памяти нода далеко позади php.

Короче, и тут тоже нужно исходить из требований, а не ориентироваться на платформу, имхо.
Sign up to leave a comment.

Articles