>>1919860

Откуда этот миф про микросервисы, которые якобы проще поддерживать? Микросервисы - это зло, к которому приходится прибегать, когда очень большой объем кода и много людей в команде, чтобы каждый пилил свою часть.

Это дрянь, от которой лучше держаться подальше.

Суммарный объем кода в микросервисах не меньше, а больше, чем в исходном монолите. Разобраться в них сложнее и дольше, чем в монолите. Да даже запустить локально их сложнее: нужно запускать поганые докеры, которые едят место на диске огромными образами, едят память и процессор, тормозят.

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

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

Другой пример. Микросервисам A, B и C надо работать с одной и той же сущностью (например: Пользователь). Что делать? Копипастить код и поддерживать 3 варианта одного и того же кода? Когда у юзера появятся новые поля, добавлять их в три микросервиса? Выносить в библиотеку и мучаться с тем, что одному сервису нужна одна версия библиотеки, а другому - другая? Сплошная боль и мучение. А в монолите такой проблемы просто нет.

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

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

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

>>1924317

>тно" больше 0, то продавец ещё и доплачивает что-ли за покупку дайте мне этого продавца сюда - я миллионером стану? У тебя тут с логикой какие-то траблы кажется.

Кстати, хоть и хохма это, но такие продавцы есть :)))
Так что имхо не важно тут - может это булевый нуль, я хз как там все в ларавеле, но именно в том и засада двойственности - с одной стороны готовые фреймворки как бы содержат в себе надежные и проверенные решения высокого уровня, так что даже макака, почитав мануал может более менее легко разобраться что и как делать. даже без особого знания корневого нативного языка и соображалки по части алгоритмов. По итогам получается как будто бы быстро и добротно сделанный проект, и юное хвостатое дарование сияет от собственной невьебенности. Дескать, во какой проект слепило. Но на деле - это чужой проект, и слепили его те же, кто слепил ларавел, а ты только сделал тюнинг по инструкции из запчастей, не особо разбираясь в сути.
Но это как правило только начало. Макак много, они все разные, и все хотят как можно больше всяких функционалов, свистелок и перделок, подключений к херовой туче саасок и т.п.. По итогам система развивается, и народ ее активно хвалит, но мануалы становятся все сложнее и сложнее, подключаемых висюлек и пиздюлек типа плагинов становится настолько много, что хер разберешь, плюс к каждому из них свой мануал, который пока изучишь, фреймворк снова устареет. А потом выдут новые релизы постгресса или, пхп, всплывет куча деприкатов, и - правильно, опять курить раздутые мануалы, юзать сырые бета-версии обновлений, все работает по итогу черти как и хер знает как, и умельцы дабы исправить положение втыкают костыли и патчи, написанные на скорую руку и через жопу, и так далее. По итогам пятистраничный сайт администрирует сорок прогеров, которые 90 процентов времени читают мануалы к аддонам к патчам, которые к плагинам, которые для такой-то версии, которая скоро депрекатед потому что выйдет следующая более современная.
О каком нативном пхп может идти тут речь, если по мануалу можно собрать сразу мегапортал с блекджеком и шлюхами, тупо нажав с десяток кнопок типа "сделать песдато" и "подключить звезду смерти с музыкой и сканером сетчатки к иконке sucks".
Как итог, господа рубисты, пхпшники, сишники и джавошники с печалью, но не без злорадства наблюдают, в какой пиздец превращается индустрия, потирая ручки в предвкушении удовольствия от военно спортивных разьебов всей этой хуйни, так как прекрасно видят аналогию с инженерной революцией прошлого века.
Когда начав с азов и основ, инженеры от проектирования паровозов смогли дойти до создания космических кораблей, но зумеры тех лет решили, что это не эффективно, и гораздо быстрее использовать "наработки из коробки" - по итогам, когда то США построило во время войны за два года боле 5000 военных кораблей самого современного на тот момент уровня, а теперь они тратят миллиарды, но уже больше четырех лет не могут тупо даже починить два корабля, которые были построены еще в 70х, просто потому что "умники" рвали жопу на продвинутых технологиях конструирования из коробки.
Которые как бы быстрее, мощнее и проще, и которые даже макаки освоят. Вот и дорвались - просрали фундаментальные знания основ, потеряли специалистов, которые специально были заточены на то, чтобы из говна и песка делать инженерные шедевры, которые просто перестали воспроизводиться, а теперь сидят и тыкву чешут, типа - какого хера все падает и не работает?
В мануалах же написано все верно должно быть, ан нет - не работает нихера. Потому что понимания того, как и почему работает - не было и нет. Есть тупо заученные мануалы.
И что самое интересное - эти мануалы в миллион раз уже сложнее и запутаннее, чем основные принципы, лежащие в их основе, которые просто следовало бы освоить. Но - нет. Это медленно, неэффективно, там нет кнопки "сделать песдато", там из коробки нихрена нет, и за это скорее всего платить не будут.
Шикарно в общем.
Поэтому и делают сегодня программисты в десять раз больше работы, скачивая патчи и обновления, юзая косячные оемки типа елоквента и куря мануалы, как тут >>1924273, вместо того, чтобы один раз почитать мануал по бд и создать метод в три строки, который просто выполнит произвольный query через PDO. Но - для этого надо знать как работают бд! А в елоквенте пофигу, поэтому все быстрее и проще - возразят мне. И хуй что возразишь.
Но по итогам - "ускорение" программирование получается "в отрицательную сторону", так как необходимость курить все новые и новые мануалы и делать новые и новые патчи, да потом еще совещаться на консилиумах несколько дней на тему "допустимо ли использовать обработку массивов средствами пхп, или необходимо преобразовать все обработчики в методы, а массивы в объекты?". Как итог, народ вешает потом эластик на постгресс, причем блять через плагин вордпресса, и когда мы начинаем истерично ржать, с удивлением спрашивает "не, ну а чо такого?"..