Елена Степанова

Про inertia почти ничего не скажу. Про livewire - Для mvp, низкобюджетных стартапов, инди-проектов, того что по умолчанию для ограниченной аудитории и не должно быть слишком нагруженным, админок каких-то... вполне себе вариант.
Для более серьёзных вещей и с расчетом на перспективу - я бы оставалась на проверенных технологиях.
Из подводных камней - с технологической стороны - дикое смешение ответственностей. С практической - каждый чих изменения в интерфейсе - та же кнопочка счетчика, смена таба, или еще чего, реализованного без православных скриптов - это запросы на сервер. И еще - серьёзный локинг на этих технологиях, их апдейтах.
А конкретно tailwind мне таки зашёл, если его с умом готовить и выносить наборы в scss. В компании с purgecss на выходе можно получить очень лёгкий css файлик. Но он обязательно в компании с компонентами - блейд, или js -фреймворков (И это, разумеется с позиции бекендера. Если на проекте есть заведующий фронтом - то ему и править балом).
В любом случае я бы посоветовала не полагаться только на мнение других, а покрутить и пощупать всё самому. Как минимум - они на хайпе, и значит есть вероятность что все равно с ними столкнётесь рано или поздно

Вообще-то в монологе есть каналы для этого
https://github.com/Seldaek/monolog/blob/master/doc...
А так же собственно, кастомные хендлеры/процессоры. В коде ты используешь стандартный логгер интерфейс, а что куда писать и слать разруливается кофигурацией монолога через di. А если его нет, то стоит задуматься именно о нём, особенно если в перспективе еще какие-то другие форматы и способы логгирования понадобятся - всё будет разруливаться в едином месте через доп. хендлеры/форматтеры и каналы при конфигурации логгера.

- Формы более переносимы и переиспользуемы
- Формы могут быть не завязаны на аттрибуты модели и лучше выражать предметную область
- Формы проще тестировать
- С использованием форм проще вести разработку в команде
- Валидация в моделях нарушает принципы SOLID (AR их в принципе нарушает, но хотябы эту часть можно нивелировать)
- Для элементарного CRUD с минимальной бизнес-логикой можно обойтись, но если на модель завязано много логики и сценарии будут разрастаться - модель быстро превратится в божественный объект
- Лепить все валидации в одну форму-модель ничуть не лучше, чем лепить их в Ар-модель -> для каждого кейса отдельная модель-форма
-------------------
Резюме: Используйте валидацию в моделях со сценариями, пока не поймёте для чего нужны формы. Использование ради использования, без осознания - всё равно бессмысленно и беспощадно

select plainto_tsquery('документ<b>Ы</b>');
select plainto_tsquery('ru', 'документЫ');  //Вместо 'ru' - название конфигурации, которое указываете в to_tsvector при создании индекса

А функция которая добавляет вектор как у вас выглядит? при использовании to_tsvector какой язык указан?

create function fts_name_vector_upd() returns trigger
LANGUAGE plpgsql
AS $$
BEGIN
	NEW.fts=setweight( coalesce( to_tsvector('russian', NEW.name),''),'A') || ' ' ||
	        setweight( coalesce( to_tsvector('russian', NEW.description),''),'B') || ' ';
	RETURN NEW;
END;
$$;