Jedi

1. Вам нужен «контроллер подсветки». Продается в днс, например
2. У вас pst вентилятор. У него два коннектора - с их помощью можно собрать целую гирлянду вентиляторов.

Стоит ли добавлять index для полей таблицы EAV?

Добавляй конешно. Если ты уже докатился до такого состояния что затащил EAV.
Но это - вопрос не к Qna а к тебе. Ни один архитектор не умеет прогнозировать время
исполнения запроса. Это - слишком шумящая и слишном сложная формула. А знать ее можешь
только ты сам после нагрузочного тестирования. Загрузи фейковые данные. Смоделируй без индекса
и с индексом.

Ну... по возможности подумай о том чтоб как-то уйти от EAV и заменить характеристики
товара JSON-документом. Это - эволюционный путь и все к этому приходят.

Если нужны сложные индексы, то в EAV модели появляется дополнительная таблица объектов с выделенными полями под нужные атрибуты, наполняемая тригерами, и уже на них настраиваются индексы.

Скажи, зачем ты выбрал EAV модель? Зачем создал себе проблем?

В чем проблема каждому атрибуту создать колонку в таблице, сотни колонок никаких особых проблем (главная рекомендация - не делать default value, если в будущем понадобится удалять добавлять колонки), структура отлично кодом модифицируется и анализируется средствами базы данных, и главное гибко организуются многоуровневые индексы, что сложно реализовать на EAV

В первую очередь нужно использовать сервисы Ларавел. Они очень хорошо работают и постоянно улучшаются. См документацию. Далее свои классы, но не просто "тупо выносить код в сервис", а разделять классы на задачи. Все не нужно выносить в сервис, т.к. тогда без разницы, что засирать - контроллер или сервис. Лучше тогда простыня в контроллере без доп файлов. Разделяй классы на логические действия, чтобы их можно было изолированно переиспользовать. Нужно активировать юзера со сложной логикой? Класс UserActivate, который ты можешь использовать в разных местах. А не UserService, который и активирует, и удаляет, и ничем от простыни в контроллерах не отличается. Жизнь тебе не упрощает. А UserActivate упрощает, делает код легким в поддержке/рефакторинге, понятным для человеческого глаза и чистым. В такое приложение можно быстро вносить изменения, а не разгребать простыни. Простыни не из-за феншуя не любят, а потому что поддерживать их с ростом приложения все труднее. Простые по функционалу приложения превращаются в "сложнейший проект". Поэтому сервисы обязательно, но в первую очередь классы Ларавел, т.к. они покрывают большую часть потребностей.

- Начните выносить логику из экшенов контроллера в сервисы
- Для упрощения, первое время можете делать по принципу "один контроллер - один сервис", "один экшен - один метод сервиса". Если используете QueryBuilder в GET экшенах, это можно не выносить в сервисы, первое время только геморой получите
- Не бойтесь разбивать конроллеры на более мелкие. Если в контроллере много экшенов, или есть повторяющиеся слова в названиях экшенов, или экшены называются более, чем 2-мя словами, часто это признак, что контроллер выполняет слишком много действий. Например есть контроллер ArticlesContrller с экшенами createArticle, updateArticle, addArticleToFavorite, deleteArticleFromFavorite. Получается дичь, он будет бесконечно разрастаться и поддержка усложнится. Например если разбить на ArticlesController (create, update, delete, deactivate) и FavoriteArticlesController (add, delete), то станет ведь гораздо проще. Так же и с сервисами. Это принцип Single responsibility
- Если метод сервиса становится слишком большим, то лучше вынести его в отдельный класс. Например есть метод Orders::create(). Создайте папку orders там же где находится сервис, в нем создайте класс OrderCreator с параметрами в конструкторе, как у метода Orders::create() и сделайте один метод create(). Заюзайте его в классе Orders::create(). Далее разбейте OrderCreator::create() на мелкие приватные методы
- Старайтесь делать методы как можно меньше, тогда они будут более гибкими и вы сможете их использовать в других местах, так же и с классами
- А вообще, зачем пересказывать книги. Просто прочитайте Фаулера Рефакторинг. Пробуйте разные описанные там принципы, и не стесняйтесь делать прямо так, как там написано. Это очень важная книга, которые выведет ваш код на абсолютно другой уровень

Дополнительно
- Рекомендую вести какой-нибудь блокнот, где брать термины и описывать своими словами. То есть постараться понять его и зафиксировать то, что поняли
- Не занимайтесь перфекционизмом. Не бывает идеального кода. Читайте теорию, пытайтесь использовать на практике. Как можно больше практики основанной на теории
- Начинайте с малого. Не надо применять и читать сразу все
- Знайте меру. Если что-то узнали, не значит, что нужно теперь применять абсолютно везде, бездумно. Если считаете, что здесь это неуместно, не используйте, даже если написано иначе
- Параллельно можно пробовать применять различные принципы: SOLID, KISS, YAGNI, DRY. Вернее не SOLID, забудьте про него вообще, первое время только голову нагружать будет, а именно Single responsibility.
- В какой-то момент применяемые принципы могут показаться бессмысленными, тогда попробуйте что-нибудь сложнее CRUD. Например сделайте свой Pat project для практики

Вам сейчас насоветуют создать сервисы, сделать репозитории, соединить это через интерфейсы и события. Потом залетит какой-то умник и расскажет про DDD, Saga, очереди, микросервисы.
В итоге у вас простыня спагетти кода превратится в слоёный лазанья код, с огромной избыточностью и трудностями в поддержке.

Я советую сразу начать писать тесты и начать с простых методов рефакторинга вроде извлечения метода для избавления от дублирования Ссылка удалена модератором. Есть книга Фаулера "Рефакторинг"
Начинайте с этого, тогда вы будете хотя бы понимать что и зачем делаете, а не повторять карго культ.

Я бы вынес в реквест, который 422 отдаст автоматом. И для current_password есть правило password и также можно добавить different

Например так?

// # 17

function f(x, y) {  
  if (x * y < 0.5) {
    return (4 + Math.sin(y - x)) / (x / y + Math.pow(x, 2));
  } else {
    return Math.cos(Math.log(x / y)) - 4;
  }
}

function calc(x, y) {
  return Math.pow(Math.sin(f(x, y)), 3);
}

Лучше использовать библиотеки типа classnames.

const Button = ({ children, className, ...rest }) => (
  <button {...rest} className={classnames('great-button', className)}>
    {children}
  </button>
);

Здесь думаю ты найдешь нужный тебе вариант

Так

Но если мы подберем следующий роут... /posts/{post = slug}/{content = content_slug} мы по сути не проверяем, принадлежит ли данный контент текущему посту. Дырочка какая - если мы возьмём content slug из другого поста, который id = 2 (Post: id = 2), и напишем так /posts/{post: id = 1}/content_slug (наследующийся от post: id =1), мы его получим. Так не должно быть.

вот тут и надо проверять, что всё хорошо и выдавать ответ (например 404 если юзер ввел не верный URL)

Проще не значит хуже, если это решает поставленную задачу. Только я бы в в поле sort начинал записывать сотни: 100, 200, 300. На случай, если нужно будет что-то вставить между элементами.

Чем не устраивает вариант сделать сортировку и фильтрацию в стиле аналогичную в rest api?

вида - /items?filter[param1]=gte:10&filter[param2]=eq:somevalue&sort=param1,-param2&limit=10&offset=5
где filter параметры выборки
filter[param1]=gte:10
param1 - название параметра
gte(greater than or equal) - больше или равно
10 - значение

sort=param1,-param2
сортировка ответа по параметрам
по param1 по возрастанию, потом param2 по убыванию

offset - число результатов которые нужно пропустить
limit - количество результатов на выдачу (не более чем)

При необходимости получать информацию пачками - добавить пагинанацию
?page=2&per-page=10
соответственно, номер страницы в результатах при разбивке по 10 значений на страницу

Сочетание сортировки и фильтрации позволит в любом нужном порядке доставать контент(при необходимости расширяя фильтры) и не особо костылить. Конечно кажется избыточным, но делается один раз и переиспользуется потом в других местах. Ну или взять себе понравившиеся части.

Ну, а если нужна принудительная ручная сортировка нужен параметр приоритета/веса(weight) с соответствующей соортировкой по умолчанию. Больше приоритет - ближе к началу списку. sort=weight