«phpClub» — архив тем ("тредов"), посвящённых изучению PHP и веб-технологий.
Аноним 2021/01/23 20:54:14  №1919534 1
Трудоустроенные аноны, а у вас на работе интересные проекты вообще, или одни интернет-магазины? Можете рассказать конкретнее о последних проектах?
Ответы: >>1919635 >>1919792 >>1919818
Аноним 2021/01/24 07:57:51  №1919792 2
>>1919534
Только интересные крупные проекты конечно же.
Мне кажется везде так, если ты нормальный бэкендер, а не клепальщик говна на вордпрессе.
Ответы: >>1919804 >>1919808
Аноним 2021/01/24 08:09:49  №1919808 3
>>1919792
Нормальный бэкендер пишет интересные крупные проекты на go/python/net, а не на пхп.
Ответы: >>1919813 >>1919864
Аноним 2021/01/24 08:12:55  №1919813 4
Ответы: >>1919821
Аноним 2021/01/24 08:19:56  №1919821 5
>>1919813
Сейчас модно пилить говно на го.
И хорошо, если это говно пилят в виде микросервисов. А то ведь попадаются макаки, которые пытаются на го писать как на пхп в монолитном стиле
Ответы: >>1919853
Аноним 2021/01/24 09:18:02  №1919853 6
>>1919821
О, кстати, поясните пожалуйста вкатуну за совмещение php и go. Когда такое может пригодиться, и как это вообще реализовывается?
Ответы: >>1919860
Аноним 2021/01/24 09:21:30  №1919860 7
>>1919853
Когда у фирмы есть старый монолитный продукт на пхп, он приносит прилично денег, а на поддержку это говна уже никаких нервов не хватает.
Тогда берут это монолитное говно и потихоньку распиливают на микросервисы, которые поддерживать на порядки проще.

Тебе как вкатуну это всё нахрен не надо. Бери один язык и катись. Оставь распил легаси говна тем, кому это интересно.
Ответы: >>1919864 >>1921301
Аноним 2021/01/25 13:42:04  №1921301 8
>>1919860

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

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

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

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

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

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

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

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

Микросервисы требуют большего расхода рабочего времени на разработку и поддержку. Потому они и подходят большим компаниям, где много рабочей силы.
Ответы: >>1921940
Аноним 2021/01/26 06:34:36  №1921940 9
image.png (89, 638x417)
417x638