Pull to refresh
14
0
Роман Журавлёв @Zhuravljov

User

Дело даже не в том, чтобы именно по канону. Кроме прочего, просто так удобнее. В случае с разделенными php-fpm и nginx вы будете использовать официальные образы с поддержкой и актуальной документацией.

Контейнер php разворачивается и так в разы быстрее, чем БД

Это смотря как у вас организован entrypoint для php-контейнеров. У нас в проектах через entrypoint проходит полный цикл инициализации: обновляются composer-пакеты, накатываются миграции БД, и прочее.

Он гарантирует, что один контейнер не запустится без другого, и гарантирует последовательность запуска. Но не гарантирует, что к моменту готовности PHP будет готов и контейнер с СУБД. Я для этого в entrypoint использую https://github.com/vishnubob/wait-for-it, и жду пока не откроются нужные порты.

По разному может быть, и зависит от контекста.

Если не видите причин выкладывать свои работы, не выкладывайте.
Зачем столько пафоса?

Судя по перечню, вы находитесь под впечатлением yii1. Во второй версии хлебные крошки и другая презентационная обвеска к контроллеру отношения не имеют. Также есть возможность заменить все и вся, через DI контейнер и сервис-локатор. Базовый renderer меняется на twig одной строчкой в конфиге. Работа с несколькими БД, релейшены межу разными базами (например между mysql и монгой) уже есть, и с ленивой и с жадной загрузкой, как потребуется. Про поведения стоит понимать, что это, в первую очередь, обработчики событий объекта, связанные общей логикой одних бизнес-процессов, и собранные в один класс, который можно подключить через конфиг. И это трейтами не заменишь.

Кто запрещает то? Если хранимая процедура дает серьезный выигрыш по совокупности факторов производительности и сопровождаемости, то почему бы и нет.


Просто их сложнее поддерживать в актуальном состоянии. Я про условия командной разработки, где актуальность кода гарантирует VCS, а структуры БД — миграции. И тут получается, что хранимая процедура — не рыба не мясо, не код и не структура. Изменения хранимок в миграциях держать неудобно, потому что это код, и неотъемлемая часть общей логики, и было бы неплохо иметь возможность с помощью Git-а посмотреть историю изменений в этом самом коде. Но и в sql-файлах их держать тоже не так удобно, потому что нет гарантий, что хранимка скомпилится, если миграциями не обновили структуру до совместимого с ней состояния.


Но, если в команде выработаны общие подходы по работе с хранимками, то нет проблем.

Очень часто использование QueryBuilder-a уместно и оправдано. Вопрос в том, насколько хорошо продумано его API, чтобы он покрывал максимальное количество возможных кейсов.


Наиболее популярный случай, когда запрос дополняется джоинами и условиями в зависимости от внешних факторов. И, например для пагинатора, на основе одной сборки нужно построить два запроса: текущая страница, и общее кол-во страниц. Тут QueryBuilder серьезно упрощает код.


Отличный QueryBuilder у Yii2.
http://www.yiiframework.com/doc-2.0/guide-db-query-builder.html
Единственный минус — неотделим от самого фреймворка. Но в 2.1 планируют вынести в отдельный, не связанный с ядром Yii2, компонент.

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

Это само собой. Но основная мысль в том, чтобы обеспечить достаточную устойчивость к перебору.

Фрагмент из доклада про безопасность веб-приложений https://youtu.be/_i1d9M40-qc?t=1030. Там, в числе прочего, про то, почему для паролей MD5 использовать опасно.

Не могу сказать однозначно что правильно, а что — нет. Вариант, который вы озвучили, вполне имеет право на жизнь на ряду с прочими. Только я бы не на return ориентировался, а на перехват исключения брошенного в процессе выполнения задания. С ним проще. Его можно положить в лог, чтобы потом разобраться в причине отказа. Ну и кол-во попыток должно быть фиксированным. Потому что ошибки бывают разные. При одних действительно стоит повторить попытку, а вторые — просто ложить в лог по тихому. В общем, нужно думать и обсуждать.


А так, стоит понимать, что отправленное в очередь задание — это неотъемлемая часть логики реализованной в рамках основного процесса, но, по причине своей ресурсоемкости, вынесенная в отдельный процесс. То есть, код должен быть организован так же, как если бы вы его делали в рамках основного процесса. Если нужно перехватывать какие-то ошибки и перезапускать, то лучше делать это в коде самого job-а индивидуально.

Повторно отправить задание в очередь из Job-объекта можно так:


class SomeJob implements Job
{
    public function run()
    {
        Yii::$app->queue->push($this); // <--
    }
}

Вообще странно видеть сравнение yii2-debug и xdebug. Из общего у них только слово debug в названии.

Вечер, это сильно сказано. Секунды. И, там, где кто-то будет решать проблему, которая уже встала в полный рост, я не дам ей появиться еще на этапе разработки. Именно потому, что анализ многих моментов с помощью отладочной панели мне ничего не стоит.

Вы сейчас про альтернативную реализацию кэша. А причем тут Yii2?

Вам объясняют что, тот вариант, в одну строку, который вы предлагаете, не рабочий. И, чтобы его рабочим сделать, одной строки не хватит. get() может вернуть null, а set() возвращает результат записи в кэш, а не значение, которое вы туда пишите.


Удобство в том, что \yii\caching\Cache::getOrSet универсальный метод, который корректно покрывает наиболее распространенный кейс.


Единственное, если бы параметр \Closure $closure не стали бы делать типизированным, было бы проще. Тогда вариант в одну строку с вашей функцией мог бы выглядеть так:


$value = $cache->getOrSet($key, [$this, 'calculateSomething']);

Но и с анонимной функцией вполне удобно:


$value = $cache->getOrSet($key, function () {
    return this->calculateSomething();
});

С читабельностью все в порядке. Не пойму что именно вас смущает? Анонимные функции?


Минусы не мои.

А что не так с синтаксисом? Самый удобный вариант. Вы приводите пример с готовым значением 20. А где и как вы его будете получать? Вот именно этим и будет заниматься колбэк, если в кеше еще нет готового значения.


Наиболее распространенный кейс использования кэша:


if (($value = $cache->get($key)) === false) {
    // Тут код ресурсоемкой операции, результат которой нужно закэшировать
    $value = 123; 
    $cache->set($key, $value);
}

Теперь можно так:


$value = $cache->getOrSet($key, function () {
    // Код операции, результат которой нужно закешировать
    return 123;
});
Почему современный тренд все данные сажать на БД?

Почему вы так решили? В кастомных проектах под конкретного заказчика можно встретить целый зоопарк: что-то через СУБД, что-то в файлах, что-то в редис и т.д. Все зависит от уместности применения в том или ином случае.


А с точки зрения открытых CMS выбор очевиден. MySQL есть на каждом хостинге, и он по прежнему остается одним из самых удобных инструментом для хранения и выборки данных.

Information

Rating
Does not participate
Registered
Activity