Не до конца понятно, что вы подразумеваете под "модулями". Но подход в создании фабрики остается таким же. Каждая фабрика должна быть независима. Фабрика новости будет использовать фабрику пользователя. Фабрика пользователя будет использовать фабрику ролей. Если без этих связей модель нельзя создать.
Но в сидерах вы реализуете свою логику заполнения полей. Создаете роли, затем к этим ролям пользователей. И новости привязываете к существующим пользователям. Если вам не нужна работа фабрик внутри фабрик. В нашем примере тестируется работа страницы списка новостей. Если мы правильно поняли, то в вашем тесте вам нужно протестировать работу новостей при определенных ролях пользователя. У вас часть касающаяся подготовки данных для теста не будет такой же простой. Вам в явном виде внутри теста нужно использовать нужную роль и пользователя с этой ролью.
Я бы даже рекомендовал сделать дополнительные классы/методы для генерации данных в тестах. Которые бы создавали пользователя с нужной ролью (и авторизовывались под ним при необходимости).
В документации Laravel есть почти все и всегда коротко и лаконично. Только практика показывает, что не все так хорошо ее читают, как хотелось бы. В материале постарались объяснить, почему нужно делать именно так.
Неудобство при планировании ресурсов — оверхед на виртуализацию, необходимость иметь выделенное хранилище под образы ВМ, отсутствие гибкости в использовании дискового пространства. С контейнерами всё сильно упрощается, до уровня «скопировал-вставил».
Это всё тоже есть, используем k3s в тех же lxc контейнерах или в KVM виртуалке, но не всегда удобно и нужно. Докер используется для портативных сред разработки. Многие проекты приходят с классическим деплоем, или заказчик не хочет docker+k8s, таких кейсов, к сожалению, пока подавляющее большинство. К тому же, по нашему опыту, для многих специалистов контейнеры до сих пор выглядят как магия, или что то сильно оторванное от реальности. В общем случае, мы предпочитаем работать тем инструментом, который подходит к реализации конкретной задачи
proxmox/opennebula — работают через виртуальные диски, что создает неудобства при планировании ресурсов.
Про docker — да, мы знаем, делали, но кейс состоял в предоставлении разработчикам более привычного окружения командной строки
Боюсь, что в nginx кэш попадает весь результат, полученный от сервера — как содержимое, так и заголовки. Вся работа nginx заключается в том, чтобы собрать ключ страницы по правилу из «proxy_cache_key», проверить кэш, и если он валиден, вернуть его клиенту, либо вначале сходить на бэкенд.
Понятия уникальности контента пользователя для nginx нет. Поэтому все, что ему вернуть, он с радостью сохранит.
Директива «proxy_ignore_headers» помогает нам указать, какие заголовки не следует обрабатывать от бэкенда. Как следствие — nginx будет их игнорировать и клиенту они не дойдут.
Все верно, если любой из параметров «proxy_cache_bypass» не пустота и не «0», тогда запрос отправится на бэкенд. При этом полученный результат будет сохранен в кэш.
Если вам не нужно сохранять ответ от севера в кэш, то используйте совместно с директивой «proxy_no_cache».
Каких-то специальных метрик не снимали, эффективность работы можно проверить по графикам мониторинга — в нашем случае это zabbix.
Из графиков интересны показатели «число активных процессов», «количество соединений в секунду», вашего бэкенда(fpm/apache). Соответственно, чем ниже показатели, тем лучше.
Так как сбросом кэша управляете вы сами, можете смело увеличивать время кэширования.
Главное не переусердствовать, чтобы на каждую новую запись не происходило вытеснение, лишние операции на файловую систему никому не нужны.
В большинстве случаев рост нагрузки происходит равномерно и кэш основных страниц в пиковые моменты уже набран, а процент прохода на запрятанные url не так велик.
Если же вам это не подходит, можно самостоятельно прогревать кэш, также можете посмотреть в сторону директивы «proxy_cache_background_update».
Nginx кэш — это не замена основному кэшированию(redis/memcached/и тд), а скорее дополнение.
Наша задача — как можно меньше пропустить запросов на бэкенд.
Меньше запросов — меньше нагрузка на сервер.
Работа nginx как раз заключается в том, чтобы большая часть пришедших запросов получила заготовленные ответы от сервера. То есть nginx отдает ответ, не проваливаясь на бэкенд.
В случае с redis все запросы проходят на бэкенд, и уже бэкенд, обращаясь к redis, формирует ответ.
Если же вы имели в виду модуль «ngx_http_redis_module», то его мы не рассматривали.
Почему вы используете underscore, когда браузеры поддерживают и map (IE9+) и length?
Это скорее legacy, который в дальнейшем планируем выпилить.
В чем профит использования компонентов в вашем окружении кроме как инкапсуляции? Во всех ваших примерах компоненты функциональные и не имеют никакого поведения.
Были выбраны простые компоненты, чтобы не нагружать статью. Описание поведения компонентов это большая тема для отдельного набора статей.
Пока это выглядит как скрещивание реакта и битрикса, но у нас далекоидущие планы на дальнейшее использования реакта в том числе с другой back-end системой
Да, решение очень интересное. Но я как раз исходил из своего опыта с нашим корпоративным порталом, который предоставляет кучу возможностей, но туже кучу времени требует на настройку (это я про процессы). Хотелось сделать такой инструмент, с помощью которого любой менеджер (будь то руководитель отдела продаж или секретарь), без ИТ-отдела (обязательное условие =)) сможет сделать себе формочку с нехитрым процессом.
Скажу честно: пока с простотой не все однозначно, поэтому в ближайшее время откроем специальный мастер, где от пользователя не будем требовать добавлять, настраивать. Максимум — выбор нужных полей и шагов (чекбоксами) и ввод e-mail, а дальше — получите, распишитесь.
Не до конца понятно, что вы подразумеваете под "модулями". Но подход в создании фабрики остается таким же. Каждая фабрика должна быть независима. Фабрика новости будет использовать фабрику пользователя. Фабрика пользователя будет использовать фабрику ролей. Если без этих связей модель нельзя создать.
Но в сидерах вы реализуете свою логику заполнения полей. Создаете роли, затем к этим ролям пользователей. И новости привязываете к существующим пользователям. Если вам не нужна работа фабрик внутри фабрик.
В нашем примере тестируется работа страницы списка новостей. Если мы правильно поняли, то в вашем тесте вам нужно протестировать работу новостей при определенных ролях пользователя. У вас часть касающаяся подготовки данных для теста не будет такой же простой. Вам в явном виде внутри теста нужно использовать нужную роль и пользователя с этой ролью.
Я бы даже рекомендовал сделать дополнительные классы/методы для генерации данных в тестах. Которые бы создавали пользователя с нужной ролью (и авторизовывались под ним при необходимости).
Что-то в таком духе:
Создаем роль (если ее нет) к ней создаем пользователя и затем уже остальная логика теста. Вы также можете вызывать конкретные сидеры непосредственно из тестов:
https://laravel.com/docs/8.x/database-testing#running-seeders
В документации Laravel есть почти все и всегда коротко и лаконично. Только практика показывает, что не все так хорошо ее читают, как хотелось бы. В материале постарались объяснить, почему нужно делать именно так.
Это всё тоже есть, используем k3s в тех же lxc контейнерах или в KVM виртуалке, но не всегда удобно и нужно. Докер используется для портативных сред разработки. Многие проекты приходят с классическим деплоем, или заказчик не хочет docker+k8s, таких кейсов, к сожалению, пока подавляющее большинство. К тому же, по нашему опыту, для многих специалистов контейнеры до сих пор выглядят как магия, или что то сильно оторванное от реальности. В общем случае, мы предпочитаем работать тем инструментом, который подходит к реализации конкретной задачи
Про docker — да, мы знаем, делали, но кейс состоял в предоставлении разработчикам более привычного окружения командной строки
Понятия уникальности контента пользователя для nginx нет. Поэтому все, что ему вернуть, он с радостью сохранит.
Директива «proxy_ignore_headers» помогает нам указать, какие заголовки не следует обрабатывать от бэкенда. Как следствие — nginx будет их игнорировать и клиенту они не дойдут.
Если вам не нужно сохранять ответ от севера в кэш, то используйте совместно с директивой «proxy_no_cache».
Из графиков интересны показатели «число активных процессов», «количество соединений в секунду», вашего бэкенда(fpm/apache). Соответственно, чем ниже показатели, тем лучше.
Так как сбросом кэша управляете вы сами, можете смело увеличивать время кэширования.
Главное не переусердствовать, чтобы на каждую новую запись не происходило вытеснение, лишние операции на файловую систему никому не нужны.
В большинстве случаев рост нагрузки происходит равномерно и кэш основных страниц в пиковые моменты уже набран, а процент прохода на запрятанные url не так велик.
Если же вам это не подходит, можно самостоятельно прогревать кэш, также можете посмотреть в сторону директивы «proxy_cache_background_update».
Наша задача — как можно меньше пропустить запросов на бэкенд.
Меньше запросов — меньше нагрузка на сервер.
Работа nginx как раз заключается в том, чтобы большая часть пришедших запросов получила заготовленные ответы от сервера. То есть nginx отдает ответ, не проваливаясь на бэкенд.
В случае с redis все запросы проходят на бэкенд, и уже бэкенд, обращаясь к redis, формирует ответ.
Если же вы имели в виду модуль «ngx_http_redis_module», то его мы не рассматривали.
Это скорее legacy, который в дальнейшем планируем выпилить.
Были выбраны простые компоненты, чтобы не нагружать статью. Описание поведения компонентов это большая тема для отдельного набора статей.
Скажу честно: пока с простотой не все однозначно, поэтому в ближайшее время откроем специальный мастер, где от пользователя не будем требовать добавлять, настраивать. Максимум — выбор нужных полей и шагов (чекбоксами) и ввод e-mail, а дальше — получите, распишитесь.