Откройте для себя путь DDD. Доменная модель на все приложение одна и не привязана к модулям фреймворкам и вообще. Правда в контексте Yii сделать чистые модели не получится, php все же не ruby.
типа взять id пользователя, время его регистрации, еще какие параметры, перемешать, зашифровать через openssl к примеру и потом при запросе расшифровать и собственно найти такого пользователя?
Ratchet + websockets + fallback в long pooling (все на базе reactphp сделать и связать с основным приложением через очередь сообщений на rabbitmq/activemq/zeromq/resq/etc либо своими кастылями с базой данных). То что у вас отправлялось всем пользователем это лично ваша проблема - значит вы не разобрались как работать с websockets. У вас соединения должны быть привязаны к пользователям.
вы хотите оптимизировать выборки из массивов? Изобрести индексы для массивов? (можно реализовать механизм индексации с бинарным поиском или использованием хэшмэпов для примари кеев).
Если этот массив взялся из базы данных то и выборку стоит в ней же делать.
в противном случае запись массива в базу и выборка там будет медленнее тупого перебора в лоб. Только если данные там уже и останутся и вы будете эту таблицу реюзать будет профит.
function Foo(value) {
this.value = value;
}
Foo.prototype.valueOf = function () {
return this.value;
};
var first = new Foo(2) // first.val = 2
var two = new Foo(3) // first.val = 3
alert( first + two ) // должно вывести 5
мне кажется стоит разобраться зачем вообще эта строчка там нужна (реально не понимаю, это же метод класса, зачем там брать имя себя же? Оно же вам уже известно...
Ну а так - нет, такого ничего нету, ни магических констант - ничего. Если хочется извращений - можно через __call попробовать разрулить (сделать все методы приватными) но имхо лучше вообще от этой строчки избавиться.
От дублирования кода нормально избавляться вынося онвый в приватные методы.
p.s. пожалейте людей, код класса ни за что не показывайте.
доступ к апишке инкапсулирован обычно в сервис/сервисы. Не нравится что отдают бэкэндщики - воспользуйтесь DTO, оберните все в свои объекты и работайте как хотите. Пока апишка не готова - можно временно захардкодить какие-то данные.
И да, не понятно зачем вам вообще что-то бэкэндщикам отдавать. SPA есть отдельное приложение. Если бэкэндщики хотят сделать деплоймент - то исходники им имхо полезнее, можно при сборке тесты прогонять (вы же их пишите, да?) ну и все в таком духе.
Проблемы обычно от отсутствия взаимодействия между отделами в рамках одного проекта, когда вы не вкурсе что собираются делать другие, и другие не вкурсе что собираетесь делать вы и что вам для этого нужно.
если делать прототип и потом выкидывать и переписывать с нуля - то однозначно Yii (ибо сэкономите).
в противном случае вы не сэкономите даже если на разработку было убито меньше денег (я не к тому что Yii плохой а к тому что реализация проекта на Django и на Laravel каком будет не сильно различаться в цене по хорошему. Стало быть вам либо повезло с разработчиком либо все будет делаться в ущерб качества архитектуры и гибкости в будущем).
Если вы не разработчик, то отдайте этот выбор на откуп исполнителя. Просто пропишите в требованиях обязательное наличие интеграционных и UI тестов (юнит тесты не обязательно, достаточно на Behat/Cucumber тесты написать (вне зависимости от выбора, PHP, Ruby, Python), причем тут вы можете поучавствовать). А еще лучше после какого-то этапа (допустим проект готов на 20%-30%) закажите код ревью небольшое и в частности ревью тестов.
phantom.js на сервере, который будет рендрить ваши странички и генерить превьюшки. html2canvas.js штука забавная, и пожалуй единственная альтернатива (ну еще wkhtmltoimage), но не слишком надежно это дело делать на клиенте.
С вашей посещаемостью я бы выбрал вариант с большим объемом RAM. Нагрузка на HDD/SSD будет не такой уж и большой, главное что бы кеширование было нормально настроено.
rest api удобнее:
- api скрывает детали реализации. Хранилище может быть подменено другим, более производительным, архитектура приложения может сильно меняться по кускам
- как следствие, отдельные части приложения могут быть написаны с применением совершенно разных технологи в зависимости от требований к производительности например. Узкие места можно реализовать на go/c++ и т.д.
Если же части приложения крайне интенсивно общаются между собой, бинарные протоколы будут эффективнее за счет большей пропускной способности и меньших накладных расходов (маршализация вместо сериализации в текстовые форматы).
Опять же узкие места можно попросить общаться через бинарные протоколы (очереди сообщений например, кеши и прочее) а что-то - через rest. сильно от задачи зависит и от целей которые преследуют разработчики.
