да правильно. У нас или сырые данные или логи. но монга у нас первариват по пол терабайта данных в сутки
А можно уточнения что за проект/специфика данных?
Antony
Ян
сделай себе backend под админку и api для апи. толькл не на уровне потрохов модуля, а на уровне самих модулей. /api/web/index.php
Antony
именно. но станет это злом или нет уже от тебя зависит. у тебя в моделях будут явно объявлены поля. миграции не нужны. структуру твоих данных в базе должна определять твоя модель данных
А если меняется структура данных, то накладно ли будет менять структуру всех данных в nosql?
Ян
сделай себе backend под админку и api для апи. толькл не на уровне потрохов модуля, а на уровне самих модулей. /api/web/index.php
ненужно рушить структуру фреймворка. в нем уже есть альяс @webroot к примеру который смотрит в /web
Ян
Ян
если оно уложится в один запрос - сделай одним запросом
Dmitriy
ну да. два ж приложения. а зачем плодить еще одну точку?
не ужели 2 разных точки это удобно ? я тупо беру стандартный шаблон и разделяю по модулям
Antony
Букинг Экспедия еще 100 партнеров парсим
Ну на такие объемы данных не рассчитываем. Тем более данные будут однородные
Ян
я не пробовал монго на йии. я нашел коннектор и всплакнул, все. с монго я работал на рельсах
Ян
не ужели 2 разных точки это удобно ? я тупо беру стандартный шаблон и разделяю по модулям
а зачем смешивать приложения? когда они отдельны? тогда запихай все в common, из консоли в т.ч. и все будет в одном месте, удобно ж..
Ян
соблюдение разделения абстракции в йии практически фундаментально
Dmitriy
а зачем смешивать приложения? когда они отдельны? тогда запихай все в common, из консоли в т.ч. и все будет в одном месте, удобно ж..
ну api это не разное приложение . Ну А еще у меня есть страница с одной функцией. но на поддомене. не делать же для нее еще одно приложение
Ян
за счет этого у тебя есть возможность все ровно и аккуратно разделить и сохранить "сухой" код
Dmitriy
Разве модули для этого не предназначены ?
Ян
ну api это не разное приложение . Ну А еще у меня есть страница с одной функцией. но на поддомене. не делать же для нее еще одно приложение
апи это одно приложение, которое работает с общими можелями одним образом, админка другое приложение, которое работает по другому. а свою отдельную страницу можно и в приложении админки разместить, если оно расти не будут, а если в будущем планируется расширение, то 3е приложение
Ян
Разве модули для этого не предназначены ?
модуль это кусок приложения, не нужно в него запихивать целое приложение
Antony
Как я понимаю в случае с апи должно быть админка, приложение апи и приложение для пользователей (к примеру, чтобы раздавать ючи для апи).
Dan
делаем по мануалу рест апи на yii, столкнулись с тем, что нет файла common/config/aliases.php это нормально?
Dan
или надо его создать?
Antony
Причем приложений для апи можно делать несколько (для версий/обратной совместимости).
Я прав?
Dmitriy
модуль это кусок приложения, не нужно в него запихивать целое приложение
api это тоже кусок приложение. тем более он использует все те же entity
Dmitriy
Ян
делаем по мануалу рест апи на yii, столкнулись с тем, что нет файла common/config/aliases.php это нормально?
альясы в main лежат. просто кто-то вытащил его наружу
Ян
я вот роуты наружу вытаскиваю
Dmitriy
апи это одно приложение, которое работает с общими можелями одним образом, админка другое приложение, которое работает по другому. а свою отдельную страницу можно и в приложении админки разместить, если оно расти не будут, а если в будущем планируется расширение, то 3е приложение
меня больше смущает несколько точек входа. вот у симфони есть бандлы. создал бандл и разделил как тебе нужно с единой точкой входа
Ян
Причем приложений для апи можно делать несколько (для версий/обратной совместимости).
Я прав?
а тут уже спорно. если версии отличаются симводически то можно и модулем обойтись, который унаследует предылущий
Ян
а если все по другому то можно и приложение запилить
Antony
а тут уже спорно. если версии отличаются симводически то можно и модулем обойтись, который унаследует предылущий
Ну тут зависит от различий, совместимости и поддержки.
Я привел как пример.
Ян
если модуль, то его функционирование будет зависить от конфигов застореных в репозиториях, а если приложение, то можно рулить и на сервере через локальный конфиг или вообще на уровне http сервера
Antony
меня больше смущает несколько точек входа. вот у симфони есть бандлы. создал бандл и разделил как тебе нужно с единой точкой входа
Ну а разве одна точка входа не создает оверхед на роуты?
Ян
Ну тут зависит от различий, совместимости и поддержки.
Я привел как пример.
ну я так и сказал по сути)
Ян
но это если роуты явно заданы
Ян
можно ведь и автороутинг юзать
Ян
по контроллеру и экшену
Ян
не так красиво, но эффективнее, без обращения к ищачьему массиву роутов
Ян
и будет работать тупо автолоадер, который и так работает
Antony
В йии же тоже роутинг построен на контроллере/екшене.
Но если разделить контроллеры на разные точки входа (в теории) можно избавиться от небольшого оверхеда.
Но это уже тянет на микрооптимизайии
Ян
В йии же тоже роутинг построен на контроллере/екшене.
Но если разделить контроллеры на разные точки входа (в теории) можно избавиться от небольшого оверхеда.
Но это уже тянет на микрооптимизайии
это уже жирный конфиг http сервера) или регулярки. в любом случае так же лишняя работа
Ян
если не использовать явные роуты то пофиг
Ян
чем больше массив тем дольше из него выборка
Ян
как его не кешируй
Antony
это уже жирный конфиг http сервера) или регулярки. в любом случае так же лишняя работа
Мне кажется все равно если настроить нжинкс будет чуть быстрее, нежели разбирать большие роуты на пыхпх
Ян
а вложеные роуты в модулях тем более зло
Ян
Мне кажется все равно если настроить нжинкс будет чуть быстрее, нежели разбирать большие роуты на пыхпх
но можно и там и там все оставить максимально просто
Ян
по умолчанию йии парсит контроллер и экшен из урла
Ян
так что если их не объявлять, то он будет сразу хватать контроллер, без переборов
Antony
Вообще роутинг отдельная тема.
В определенных случаях роутинг на if'ах бывает быстрее же.
Ян
а вообще если экономить, то на AR
Dmitriy
согласен, но я только что отметил новый год и можно похоливарить)
я каждый день работаю, мне тоже можно
Antony
Но эти оптимизации реально могут быть полезны на больших проектах
Antony
Ну для АР если генерировать через гии формы для добавления, то идет запрос в бд же.
Так что я стараюсь модели для форм выносить отдельно
Dmitriy
Но эти оптимизации реально могут быть полезны на больших проектах
Вот тогда и будем про нее говорить. а преждевременная оптимизации зло.
Ян
я не о том
Ян
у него большие накладные расходы на обработку структуры таблицы и на магию компонента
Ян
запрос через голый pdo с получением массива будет в разы быстрее
Ян
если не в сотни раз
Antony
Вот тогда и будем про нее говорить. а преждевременная оптимизации зло.
Ну оптимизации могут быть изначально заложены, если ты знаешь/требуется большая нагрузка.
Иначе это не столько зло, сколько перерасход рабочего времени
Dmitriy
А если нет ? мы потеряем время и деньги. Ну если компания типо маил ру то да у них оптимизация должна быть
Ян
Ну оптимизации могут быть изначально заложены, если ты знаешь/требуется большая нагрузка.
Иначе это не столько зло, сколько перерасход рабочего времени
ненадо закладывать оптимизацию, надо закладывать ее возможность
Ян
т.е. максимальная абстракция и никакого хардкода
Dmitriy
Тут в соседнем чатике сказали что разделять методы на пост и гет не оч. что думаете ?
Ян
Тут в соседнем чатике сказали что разделять методы на пост и гет не оч. что думаете ?
я все думаю хочу туда или нет
Dmitriy
На вопрос, гражданин
Antony
Ну ты должен явно понимать узкие места при нагрузках и где можно сэкономить.
Ну пост/гет/пут/делит это же основа рестфул
Ян
у меня время 4 38, я подвыпил, начинаю отключаться и пишу с телефона)
Antony
Соседний чат это пхпгикс?
Dmitriy
Но мне там доказывают что не нужно разделят на пост и гет. что в yii2 норм не разделять отвественность
Ян
Antony
А ссылку можно?
Dmitriy
да уже все, все ушли