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