Комментарии 27
Я делал иначе:
1) есть команда создания соединения, она поднимает само соединение и отправляет на роутер.
2) Внутри роутера валидируется реквест и формат сообщения (в моём случае jsonrpc)
3) Далее реквест отправляется в нужный контроллер, в зависимости от поля «method» в jsonrpc.
4) При наличии ошибок или ответа из контроллера — можно сопоставлять «id» сообщений для псевдосинхронного выполнения (опять же кусок jsonrpc стандарта)
Плюс с помощью DI в контроллеры подсовываются пул соединений, таймеры и прочие хелперы.
Т.е. в моём случае контроллеры выполняют действия на запросы клиента (в т.ч. могут инициировать свои), а модели являются некими сущностями, изолированными от респонза. Вроде это в MVC называется «пассивная модель».
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 имеет смысл на клиенте, где у нас контекст приложение живет дольше чем один запрос.
А в Laravel и Symfony классический MVA
Роль адаптера выполняют GRASP-контроллеры.
Самое важное — и в том и в другом варианте контроллеры отвечают только за первоначальную пред-обработку данных для последующей передачи в модель. А уже в модели будут происходить манипуляции с данными связанные с логикой приложения.
Что до websockets — опять же никакой разницы, так как мы всеравно будем асинхронные действия пользователя ловить в контроллере и просить приложение что-то сделать.
Хотя опять же ничего плохого в толстых контроллерах и тонкой модели нет, иногда это удобно.
Отлично, ставлю плюс.
Тоже пилю небольшой амбициозный проект, но там правда API буду использовать не для фронтенда, а для мобильных приложений. Тоже в своё время малость игрался с настройкой nginx, так как нужно было разделить по поддоменам основной сайт и его api.
Тоже пилю небольшой амбициозный проект, но там правда API буду использовать не для фронтенда, а для мобильных приложений. Тоже в своё время малость игрался с настройкой nginx, так как нужно было разделить по поддоменам основной сайт и его api.
Спасибо за поддержку. А так же все кому интересно ссылка на мой проект
Очень интересно почитать про разработку Frontend и Backend. Ради любопытства решил небольшой проектец сделать — рейтинг игроков по настольной игре. То есть ничего сложного, в принципе. А в Yii насмерть, оказывается, зашит Boostrap. Хочется как-то использовать тот же Angular UI, а колхозить с самого начала не хочется.
Так используйте Yii в качестве REST сервера, тогда вам будет совсем не важно какой frontend использовать.
И готовить страницу на клиенте полностью? С REST придется возиться со всякими индексациями поисковиками как раз. И я как-то пока не очень верю в SEO-безоблачность такого подхода.
С другой стороны, не очень хочется на столько глубоко разделять технологии fronend и backend. У меня же не HighLoad предполагается.
Хотя за мысль все равно спасибо. Может в конечном итоге использую как раз такой вариант. Я просто по началу посмотрел как Yii генерит поля для формы в шаблонах. Подумал, что здорово было бы также сгенерировать некий интерфейс на frontend, но только с Angular UI. А для этого, похоже, немало усилий нужно приложить.
С другой стороны, не очень хочется на столько глубоко разделять технологии fronend и backend. У меня же не HighLoad предполагается.
Хотя за мысль все равно спасибо. Может в конечном итоге использую как раз такой вариант. Я просто по началу посмотрел как Yii генерит поля для формы в шаблонах. Подумал, что здорово было бы также сгенерировать некий интерфейс на frontend, но только с Angular UI. А для этого, похоже, немало усилий нужно приложить.
>в Yii насмерть, оказывается, зашит Boostrap
это не так, вы можете использовать бутстрап, можете не использовать. Boostrap используется в утилитах yii, и в некоторых виджетах.
это не так, вы можете использовать бутстрап, можете не использовать. Boostrap используется в утилитах yii, и в некоторых виджетах.
Отключить bootstrap можно в assetManager
А так же можно тащить пакеты из bower/npm через composer. Либо отдельно поставить npm, немного инфы тут
> if ( $http_user_agent ~* (...) ){
> rewrite ^ /snapshot${uri};
> }
Очень похоже на cloaking. Google за такое по рукам не бьет?
UPD: А, не, отдаются ведь снепшоты тех же страниц, тогда все ок
> rewrite ^ /snapshot${uri};
> }
Очень похоже на cloaking. Google за такое по рукам не бьет?
UPD: А, не, отдаются ведь снепшоты тех же страниц, тогда все ок
Так же в случае падения надо перезапустить данный процесс. Не нашёл решение более элегантного, как через каждую минуту запускать команду в crontabSupervisor: A Process Control System
Создание снапшотов хорошо работает, если у вас небольшой сайт. А если у вас на сайте тысячи страниц, генерируемых и обновляемых пользователями?
Есть вот такой подход https://github.com/steeve/angular-seo
Немного погуглив, нашел информацию о ?_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
Ну а как мне понять что отдавать — статику или динамику? Можно пример конфигурации?
Возник вопрос — я использую html5mode. У меня есть страница, которая открывается по адресу example.com/news/22
Ну а как мне понять что отдавать — статику или динамику? Можно пример конфигурации?
по юзерагенту, примерно так же как как у вас со снэпшотами сделано. Просто чуть больше юзер агентов надо добавить. В остальных случаях при отсутствии файла. к которому мы обращаемся, отдавать index.html.
Из вариантов посложнее и интереснее — серверный пререндер (для React, Angualr2, Ember и других штук поддерживающих server-side рендринг), который чаще используется для улучшения UX, но и для поисковиков норм. В этом случае алгоритм будет одинаков для всех. Засылаем запрос в express-сервер какой-нибудь, тот запускает рендринг первоначальный приложения и выплевывает на клиент. Когда подтягиваются JS либы приложение оживает, но пользователь уже видит в принципе оное с каким-то состоянием, что собственно и улучшает UX.
Конечно же этот подход намного сложнее так как вводит ограничения на то, что мы можем делать и как примерно все это должно работать (например stateless UI, проход данных сверху вних и т.д. при таком варианте все это можно организовать относительно малой кровью).
Из вариантов посложнее и интереснее — серверный пререндер (для React, Angualr2, Ember и других штук поддерживающих server-side рендринг), который чаще используется для улучшения UX, но и для поисковиков норм. В этом случае алгоритм будет одинаков для всех. Засылаем запрос в express-сервер какой-нибудь, тот запускает рендринг первоначальный приложения и выплевывает на клиент. Когда подтягиваются JS либы приложение оживает, но пользователь уже видит в принципе оное с каким-то состоянием, что собственно и улучшает UX.
Конечно же этот подход намного сложнее так как вводит ограничения на то, что мы можем делать и как примерно все это должно работать (например stateless UI, проход данных сверху вних и т.д. при таком варианте все это можно организовать относительно малой кровью).
Я бы посоветовал стек
React + nodejs + phalcon или React + nodejs )
это более серьезное решение
React + nodejs + phalcon или React + nodejs )
это более серьезное решение
это более серьезное решение
Это очень субъективная оценка.
К сожалению найти толковых разработчиков которые не испортят все на ноде — это еще поискать надо. Их даже меньше, чем адекватных PHP разработчиков. По поводу react vs angular — тут опять же, зависит от задачи. Если надо быстро и изоморфно — angular2 проще, поскольку фреймворк предоставляет готовую инфраструктуру. С реактом придется все это собирать (хотя это не сильно сложнее на самом деле). В целом же опять же все упирается в адекватных разработчиков, а адекватные разработчики сделают нормально в любом случае.
phalcon же несет в разы больше рисков чем node.js или php. Сегодня вы счастливы а завтра ищите сишников, или php-ников которые нормально владеют gdb + strace
да не, все гораздо проще ))
React потому, что возможностей больше
phalcon потому, что быстрее и меньше кушает. Там уже давно все ровно и поиски сишников не нужны ). Глянул код на зефирке, который не сильно отличается от пэхапэ и все стало ясно.
Ну, а nodejs потому, что она быстрее пэхапэ )
А вот прямота рук влияет на любой инструмент, это отдельная тема )
React потому, что возможностей больше
phalcon потому, что быстрее и меньше кушает. Там уже давно все ровно и поиски сишников не нужны ). Глянул код на зефирке, который не сильно отличается от пэхапэ и все стало ясно.
Ну, а nodejs потому, что она быстрее пэхапэ )
А вот прямота рук влияет на любой инструмент, это отдельная тема )
Скорость ноды — довольно субъективная оценка, т.к. php 7 показывает результаты превышающие аналогичные нодовские. С другой стороны на ноде проще (т.е. это не значит, что и на пыхе нельзя) параллелить операции, за счёт чего можно получить неплохой такой профит. В любом случае по количеству сжираемой оперативной памяти нода далеко позади php.
Короче, и тут тоже нужно исходить из требований, а не ориентироваться на платформу, имхо.
Короче, и тут тоже нужно исходить из требований, а не ориентироваться на платформу, имхо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я писал web app angular + material и REST на Yii2 + webserver nginx