Нет таких планов

я свалил из такого говнолегаси, не доведя новую (пхп 5.3 -> 7.2 ) версию до прода. хотя она +- была готова. вообще не жалею ни капли.

Ну если есть выбор шанс не воспользоваться таким

Другое дело если ты всю эту кашу начинал и свалил ниче не сказав это уже другая история

Про переписывание легаси проектов - хорошо себя показал способ такой:
- поднимаем скелет нового проекта рядом со старым, на том же домене
- подключаем новый проект к старой базе и прочим важным стейтам
- делаем сквозную аутентификацию и авторизацию между проектами
- потихоньку, буквально по одному роуту/сообщению переносим фичи, прежде всего те, по которым текущие задачи идут
- роуты те же, разруливаем на уровне nginx или что там у ваc по location - кидать их на разные апстримы в fastcgi_pass. Хотя можно и роуты переписывать, главное чтобы перенос ещё одной фичи на новый проект не требовал изменения старого
- новый проект пишем по уму, с тестами, пайплайнами, архитектурой нормальной и т. п.

Несколько проектов так перевёл или, хотя бы поставил процесс перевода без своего особого участия как лида. Хороший момент продать такое бизнесу  - когда заходит какой-то эпик,

@zGalifax, можно и без него, если ойпишнег белый.

Старт демона на ойпишнеге:
sudo dockerd -H unix:///var/run/docker.sock -H tcp://<ip>:<port> -H tcp://<ip>:<port>

Работа с докером на ойпишнеге:
docker -H tcp://<ip>:<port> ps

или

export DOCKER_HOST="tcp://<ip>:<port>"
docker ps

https://docs.docker.com/engine/reference/commandline/dockerd/

export DOCKER_HOST="tcp://<ip>:<port>"
docker ps

Спасибо

export DOCKER_HOST="tcp://<ip>:<port>"
docker ps

если на компе белый... если только на роутере, то ещё порт пробросить. если динамический то какой-нить динамик ДНС подключить - хорошо если роутер поддерживает. Это если домен есть )

> если только на роутере

Думаю, вполне очевидно, что имеется ввиду выдданный на устройство клиента ойпишнег. А чо там за устройства уже сам пользователь должен решать.

Прокинуть порт на роутере это вообще изи.

Нам очевидно, а вот тем, кто подобные вопросы задаёт - не факт. Могут даже не знать какой у них айпишник (

то же самое хотел предложить. все так.

да уже дешевеют и выбор людей в разы больше)

нравится что у них стек и тулинг можно сказать стандартизирован, если взять какой-то условный реакт и все что возле него

Да там общего часто только сам react да react-router от проекта к проекту. Хорошо если create-react-app структура общая и конфиги не еджекнуты, а вот уже внутри src кто в лес, кто по дрова. Стейт-менеджмент, асинк, взаимодействие с бэком, валидация форм - кто сам пишет, кто либу на свой вкус берёт.

а какой может быть разный асинк то?)

ну и я не говорю про помойные проекты, куда даже не завезли тс

почти везде идет +- одинаковый eslint, prettier, redux, хуки, formik/hook-forms, сейчас начал добавляться rtk

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

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

и вот внутри реакта в целом все довольно стабильно и понятно

вот и имеем овер дофига вакансий и к ним же спецов, где проекты под копирку

с бекендом не так радужно, к сожалению

сага, санк, из MST обвязка для генераторов

А я не говорю про помойные проекты с редаксом, куда его затащили потому что статью своего идола Абрамова "вам не нужен редакс" не прочитали ) По формам ещё final-form хорош, мне больше формика нравится

это все же минимальные различия.

не такие что тут у нас гошка (на которой своих 10+ основных фреймворков), а тут у нас пхп на любой вкус. тут икомерс, а тут мы крипту фигачим

Хороший вопрос на проверку адекватности технического менеджмента на проекте "почему у вас редакс на проекте? Зачем, какие его свойства для вас киллер-фича"

ну это да, по сравнению с бэком так даже ангуляр с реактом - близнецы-братья