Всё пропало, файловые блокировки выпилили?

fixxxer

К.О.
Партнер клуба
впрочем, какая разница, ты уже решил задачу пачкой денег
На самом деле линуксом, без пачки денег можно было бы и обойтись)

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

кстати, я не очень понимаю, как с вендорами в нативном volume их должен видеть phpstorm.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
ну, настроить мапинг папок
для автокомплита в IDE можно отдельно поставить вендоров как справочник - исполняться они не будут, редактировать их не надо, а прыгать в дебагере по ним можно

только не надо про уникальные либы с отдельными виндовыми версиями, дебажить по ним не надо :)

что такое инкрементальная компиляция и почему она тормозит - я не знаю 🤷‍♂️
 

fixxxer

К.О.
Партнер клуба
для автокомплита в IDE можно отдельно поставить вендоров как справочник - исполняться они не будут, редактировать их не надо, а прыгать в дебагере по ним можно
С монорепой еще можно себе такое представить, а настраивать таким образом кучу микросервисов довольно утомительно, особенно когда в вендорах еще пачка своих собственных библиотек, которые меняются относительно часто.
что такое инкрементальная компиляция и почему она тормозит - я не знаю 🤷‍♂️
Я не разбирался, но подозреваю, что всякие inotify нормально не пробрасываются, и все сваливается в рекурсивное сканирование.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
а что, у тебя пачка разнородных сервисов в одной репе?
в одном проекте в IDE можно несколько приложений с разными Content Root открыть, но зачем?
ты либы редактируешь прямо в External Libraries, не создаешь для них отдельный проект?
 

fixxxer

К.О.
Партнер клуба
а что, у тебя пачка разнородных сервисов в одной репе? или в одном проекте в IDE несколько независимых сервисов с разными Content Root открыто?
ты либы редактируешь прямо в External Libraries, не как отдельные проекты?
Нет, нет, нет.

Да если бы был описываемый тобой бардак, было бы проще в этом смысле:

для автокомплита в IDE можно отдельно поставить вендоров как справочник
Затрахаешься их отдельно ставить для каждого микросервиса.

Я как-то уже привык, что склонил репы, запустил docker-compose up и готово, можно работать. Всякую подготовительную шелуху, когда надо потратить часы на подготовку среды разработки, вспоминаю с ужасом.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
зачем отдельно для каждого? просто шаблон проекта создай, и из одной папки подключай
 

fixxxer

К.О.
Партнер клуба
Из какой одной папки, если зависимости разные?

Один микросервис может запросто использовать версию 2.0 библиотеки, а другой - версию 3.0.
 

fixxxer

К.О.
Партнер клуба
Почему же? Это ж не монорепа, какой смысл обновлять то, что стабильно работает, и где не нужны новые фичи зависимости?
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
потому что у тебя геометрический рост количества зависимостей
в крупных проектах с парой сотен разработчиков приходят к приведению всего кода к одной версии библиотеки, даже если для этого надо переписать старый сервис
 

fixxxer

К.О.
Партнер клуба
А какая разница, сколько там зависимостей в сумме у всех сервисов? Каждый микросервис - это самостоятельное приложение, в нем ничего не растет.

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

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Каждая версия завязана на свой runtime и системные либы, а на системные либы завязана версия OS в образах.
Когда в проекте, например, 50 сервисов - каждый на своем runtime, своей OS, за несколько лет авторы уходят, и зависимостей уже никто не знает.
Часть проекта собирается gulp2, часть - gulp3, часть - gulp4, каждому нужна своя версия ноды, формат конфигов несовместим, еще будет 3 версии php, несколько версий openssl и libxml.
Я помню подобный проект - это авгиевы конюшни, директор разработки регулярно ночевал в офисе на коллах из-за внезапных падений в неожданных местах. Ловить баги было довольно интересно! Однажды встретилась довольно серьезная проблема в неподдерживаемой версии runtime, пришлось останавливать разработку и срочно обновлять кучу кода.

Нормально - это когда есть корпоративный baseline с определенной версией OS и runtinme, у каждого сервиса есть owner, который обязан обеспечить совместимость всех сервисов с общим набором библиотек, и общие библиотеки BC не ломают. А если надо поломать - например, для обновления PHP с 5 до 7, то вместе со всеми сервисами, которые их используют. Это работает, на крупных проектах большинство людей занимается именно обновлением сервисов под новые версии и рефакторингом .
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Это крайности. А когда один миркросервис на последней версии фреймворка, а другой пока ещё на предпоследней - это совершенно нормальная и обычная ситуация.
Какой-нибудь оракл наверное может себе позволить все бросить и обновлять все сразу. Мы нет.
 

WMix

герр M:)ller
Партнер клуба
я думал в этом смысл, распилить проект по зависимостям и решать задачи каждого сервиса по отдельности, и да, после распила может остаться что-то на старой версии, но это не мешает другому сервису развиваться
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
не ну, про все плохо сделанное в мире говорят "некогда"

я прямо сейчас скачал и запускаю образы сервисов размером 14 Гб с 3-мя разными версиями ноды
 

fixxxer

К.О.
Партнер клуба
Вот гигабайтные образы, в которых запихана куча всего - это точно сделано плохо =)

Бейзлайны это подход для крупного бизнеса, которым надо менеджить огромную сложность. Там оверхед на его поддержку и на проблемы вида "чтобы перейти с node 10 на node 12, надо пройти 100 кругов бюрократического ада" так или иначе окупается.

В малом бизнесе же эта вся бюрократия не имеет никакого смысла, поскольку будет стоить времени (=денег) не давая ничего взамен, достаточно поддерживать все в разумных рамках. Задача то не бюрократию развести, а оптимизировать TCO. Тут примерно как с техдолгом (а в твоем случае с образами по 14 гб это и есть техдолг):

 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
"какой смысл обновлять, если у меня на линуксе все работает" = техдолг

в офисе ж сеть нормальная - пофиг размер образов, на линуксе шары не очень тормозят - десктопы с линуксом, зачем решать задачу, если можно купить железо? :)
а тут по vpn это качается весь рабочий день, не все хотят домой линукс, и "какой смысл" внезапно стал дорогим техдолгом!
никогда такого не было - и вот, опять
ты считаешь, что ты не такой, как все, и у тебя этого не будет? я сегодня целый день смотрел на таких, как ты, через несколько лет )))
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Образы у меня все маленькие, с чего ты взял? Я вообще не понимаю, как они могут быть большими. Ты вендоров в образ что ли кладешь? Это примерно то же, что их коммитить в репоз, если чо.

А проблема с I/O - это проблема реализации docker-desktop. Решать ее костылями типа "установить вендоров в volume и держать их копию для IDE" и подводить под это теорию, что так и надо? Нет, спасибо.

Есть docker-sync тот же, который проблему вполне себе решает. Десктоп с линуксом я себе купил не только по этой причине, если что :)
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
нет, не я :)

а я при чем? я ж не могу решить твою проблему, которой у меня нет! про volume для вендоров - это так, фантазия...
про docker-sync я не знал, но годное решение должно быть, судя по названию, спасибо, что рассказал
 

fixxxer

К.О.
Партнер клуба
про docker-sync я не знал, но годное решение должно быть
Настраивать его и мейнтенить оверлей компоуза довольно муторно. А так проблему решает. Заодно решает и проблему UID mapping-а, которая в основном актуальна таки для линукса, хех.
 
Сверху