Богдан, При желании можно в коде конечно подключать разные конфиги .dev.env и т.д.
Но смысл в этом только для дева не создавать каждый раз например.
Для продакшна всё равно свои настройки и они ни в коем случае не хранятся в гите в готовом виде.
Богдан, так и пользоваться.
Для прода стоит один конфиг настроенный, и он не хранится в гите.
Для дева один раз настроили и забыли тоже.
Т.е. локально один раз в каждом окружении он создаётся и настраивается.
Обновляется он примерно никогда, поэтому так и работают.
Изменяется при добавлении новых конфигов понятное дело.
Логика в приложение самая простая на мой взгляд это получение с редиса и отправка клиенту;
если действительно так, то pm2 cluster выглядит как то что нужно, т.е. просто запуск нескольких воркеров и балансировка автоматическая.
Если всё посложнее, то возможно на уровне приложения надо будет делать корректную балансировку.
socket.io умеет это сам с помощью редиса и небольших твиков. https://socket.io/docs/using-multiple-nodes/
RastikRus, транзакции/блокировки. Других известных решений не знаю.
Либо отказаться от варианта с обновлением полей.
Вести полный лог неких ваших действий которые вы считаете, а считать по необходимости через count.
Либо делать это по крону например, т.е. логи обрабатывать по крону и записывать конечные данные уже потом.
mrSeller, вот лучше бы этот коммент и написали вместо всего вопроса.
Потому что вопрос вообще никак не передаёт вашу первоначальную задачу, которую сейчас описали в итоге.
Ответ остаётся тот же про мидлвари конечно, но для этого пришлось хрустальный шар доставать, чтобы угадать. :)
nastya_zholudeva, заведите стейт search.
Везде где он используется используйте геттеры стейта.
Везде где он изменяется используйте мутации(или экшены) для его изменения.
На выходе у вас везде все будет всегда синхронизировано и в актуальном состоянии.
acerrusm, я про то что когда будут решаться реальные боевые задачи, то туда начнет подтягиваться бизнес логика и соответственно всякие зависимости вроде orm/фреймворков/библиотек и т.д.
И вся эта тяжеловесная фигня будет просто убивать сервер и его производительность, т.к. пхп создан чтобы умирать.
А писать внезапно не используя зависимости неудобно/долго/бессмысленно.
В общем надо очень осторожно всё это на пыхе делать.
Чтобы он например случайно не умер от 10 одновременных соединений :)
Иван Мельников, просто прямо сейчас проект в котором кто-то очень любил пользоваться возможностями субд.
Но не любил документацию и логику.
Так что в базе 300 таблиц, 30 вьюх, и пара сотен функций/триггеров.
В итоге половина логики находится в базе, а по коду нихрена не понятно что происходит.
При том что в коде тоже используются всевозможные триггеры и обсерверы событий, почему что-то вынесено в базу никто не знает. На выходе только гемор при поиске как работает та или иная функция.
Zulusho, в любом варианте можно шифровать на клиенте, но вам все равно придётся надежно хранить ключи чтобы манагер не потерял доступ к данным. По паролю например - сменил пароль - данные потерялись.
К тому же для каждого менеджера надо будет хранить свою версию данных под разными ключами.
В общем сплошные костыли ради надежного шифрования получатся.
Как ниже написали надо определиться от чего защищаетесь. Делать шифрование ради шифрования смысла вообще нет, трудозатраты только сплошные.
Обычного шифрования по статичному ключу достаточно чтобы закрыть формально пункт по недержанию данных открытыми. Если вы не собираетесь вообще сертификацию проходить, то отдельно в шифровании нет никакого смысла. Т.е. нужно либо нормально делать, либо не заморачиваться если нет к этому предпосылок реальных.
xmoonlight, хотя свули не на пыхе по сути, а расширение сишное, то все может быть не так плохо, но за кучу пакетов из композера например всё равно ссыкотно. А использовать чистый сервер естественно нафиг не нужно)
xmoonlight, не могу не относиться скептически к этому всё равно :D
Если что-то более менее боевое поднять на пых-сокетах, то уже не будет ноду обходить мне кажется))
И боюсь представить как сильно потечет память везде т.к. не рассчитано на работу в качестве демона.
AVKor, на стационарном FX6300, до сих пор играбельный, видяху бы только поменять :)
Но вот новейшие i3 в ноутах вообще какое-то говнище, хотя скорее в целом все бюджетные ноуты такие. Не понимаю как пользуются люди таким железом. Телефоны китайские и то быстрее работают.
> 4/4.
Точно, x4 же, повёлся на то что гугл показал первым результатом.
AVKor, ну так-то фен с 3 ядрами и видимо 6 потоками(?), это очень даже ничего. В свое время сидел на атлоне 2 ядерном и всё было норм, но сейчас софт вообще ни разу не завёдётся на таком древнем зле.
А все ноуты с которыми сталкивался на i3 или меньше вообще не юзабельны. При открытии страницы в браузере весь комп подвисает, к такому жизнь меня не готовила.
twobomb, у меня атлон 215 был лет уже наверно 7 назад, но тогда я только в блокноте кодил, конечно проблем никаких не было.
Сейчас висит собирающийся фронт, пачка докер контейнеров, пачка софта от JetBrains и уже 8 гб рамы в упор и процессор надо явно не двух ядрёный, или по крайней мере 2 ядра/4 потока.
А почему так приспичило?
Это же в разы дороже чем держать свой парк серверов(а если не парк, а парочка, то тем более) напрямую от крупных ДЦ.