нод модули лежат на одном уровне с webpack

Добрый день, в каких случаях стоит использовать store rehydration?

но путь то вы указываете абсолютный от корня? это правильно?

ну да

Привет всем, новый коллега с большим опытом разработки, говорит, что все что можно сделать в бд, лучше сделать именно там: хранимки, триггеры, вьюхи.
Вставку и изменение данных вызывать через функции в бд...
Я же считаю, что в бд, лучше не делать никакой обработки данных, максимум каскадные функции на удаление/обновление, если критично.

Выскажите своё мнение, по этому поводу. Спасибо

Это регексп

Ну у меня на одном уровне лежат  node_modules  и webpack конфиг

точно, не заметил что нет кавычек, сорри)

Почему выскакивает эта ошибка? с  watch

может надо добавить какое-то свойство в watchOptions?

Это не в вебпак

А в терминал

Если у тебя unix

Как пофиксить?)

*ИМХО*
Хранимки сами по себе не зло и не добро. Всё зависит от того как их применять. В критических по производительности местах без хранимок не обойтись. Но БД прежде всего место для хранения данных, а не для бизнесс правил(поведения приложения). БД предоставляют удобный DSL для доступа к данным, поэтому операции проекции данных(фильтрация, аггрегация и пр.) резонно стараться по максимуму выносить внутрь БД, чтобы как можно меньше этих операций выполнять в приложении.
Почему бизнесс логика в БД плохо? Потому что сложно писать, дебажить, поддерживать, практически не возможно тестировать(юниты не попишешь). К тому же в СОА бизнесс транзакция может требовать участия больше одного сервиса, тогда транзакции в БД перестают работать как гарантия консистентности, нужно изобретать свои(саги).
Но опять же, it depends. В некоторых секторах(например финтех) очень много логики описанно в БД, и ничего, живут. Правда скорость разработки при этом не назовешь. Если вы больше расскажете про ваш домен/архитектуру, то можно будет детальней обсудить + и - логики в БД в вашем случае.

Я уже в консоли добавлял  echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

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

Ну и учтите, что все скажут своё ИМХО, которое надо пропустить через призму своего опыта. Ну и не стесняйтесь спрашивать у своего более опытного коллеги, почему он считает именно так, а не иначе :)

побольше ИМХО в тексте)

что за неувереность