Трудоустроенные аноны, а у вас на работе интересные проекты вообще, или одни интернет-магазины? Можете рассказать конкретнее о последних проектах?
>>1919534Только интересные крупные проекты конечно же.Мне кажется везде так, если ты нормальный бэкендер, а не клепальщик говна на вордпрессе.
>>1919813Сейчас модно пилить говно на го.И хорошо, если это говно пилят в виде микросервисов. А то ведь попадаются макаки, которые пытаются на го писать как на пхп в монолитном стиле
>>1919821О, кстати, поясните пожалуйста вкатуну за совмещение php и go. Когда такое может пригодиться, и как это вообще реализовывается?
>>1919853Когда у фирмы есть старый монолитный продукт на пхп, он приносит прилично денег, а на поддержку это говна уже никаких нервов не хватает.Тогда берут это монолитное говно и потихоньку распиливают на микросервисы, которые поддерживать на порядки проще.Тебе как вкатуну это всё нахрен не надо. Бери один язык и катись. Оставь распил легаси говна тем, кому это интересно.
>>1919860>>1919808>>1919804С пруфом показываешь какой крупный ВЕСЬ проект пишешь на GO/тобой перечисленное, или идёшь учить уроки.
>>1919876> postgress > крупный проектЗасмеялся-проиграл тред? В больших проектах на таких СУБД только хранят всякую мелочь.Ну-ка покажи количество строк в этой базе данных.
>>1919901Вот для чего нужен GO - это тупо дома для себя что-то там поделать на выходных и забыть, ну ещё впарить на говнокурсах. Так нахуй никому не нужен, говорю)У меня в базах в одной таблице по 300 миллионов данных, со связями с другими таблицами - у меня за одну-две секунды это всё переваривается на PHP. Я хуй знает для чего GO)
>>1919860Откуда этот миф про микросервисы, которые якобы проще поддерживать? Микросервисы - это зло, к которому приходится прибегать, когда очень большой объем кода и много людей в команде, чтобы каждый пилил свою часть.Это дрянь, от которой лучше держаться подальше.Суммарный объем кода в микросервисах не меньше, а больше, чем в исходном монолите. Разобраться в них сложнее и дольше, чем в монолите. Да даже запустить локально их сложнее: нужно запускать поганые докеры, которые едят место на диске огромными образами, едят память и процессор, тормозят.Монолит использует один язык, одну архитектуру и один фреймворк. Микросервисы могут каждый использовать свой язык, свой фреймворк и свою архитектуру. Разобраться в них гораздо сложнее.В монолите ты кликаешь на вызов функции и переходишь к определению. В микросервисе ты наталкиваешься на HTTP-запрос и идешь долго выяснять, кем и как он обрабатывается, потом находишь нужный микросервис, долго изучаешь как он устроен, ищешь что там происходит и где обработчик нужного тебе запроса, изучаешь его код. Одни мучения и затраты времени.Другой пример. Микросервисам A, B и C надо работать с одной и той же сущностью (например: Пользователь). Что делать? Копипастить код и поддерживать 3 варианта одного и того же кода? Когда у юзера появятся новые поля, добавлять их в три микросервиса? Выносить в библиотеку и мучаться с тем, что одному сервису нужна одна версия библиотеки, а другому - другая? Сплошная боль и мучение. А в монолите такой проблемы просто нет.Дальше, у каждого сервиса своя база данных. А что, если нескольким сервисам нужна одна и та же таблица? Опять боль, пишем синхронизацию этой таблицы между сервисами. В то время как в монолите такой проблемы просто нету.По моему, это миф, что микросервисы чем-то лучше. Они хуже. Просто когда людей в компании очень много, им удобнее работать над своей частью кода, зачастую по своим правилам на своем фреймворке и своем языке вместо того, чтобы договориться и сообща развивать единый проект в едином репозитории. Микросервисы требуют большего расхода рабочего времени на разработку и поддержку. Потому они и подходят большим компаниям, где много рабочей силы.
