Комментарии 30
GET-метод, который принимает тело
Это QUERY.
Ну нет, <SOME SYSTEM> умеет только в тело JSON передавать, сделайте пожалуйста как просят!
Так я про это и написал. QUERY-метод только обсуждается и не поддерживается, по-моему, ничем из существующего. А люди уже идут на шаг впереди, т.к. понимают что за этим будущее.
Гораздо более неприятно узнавать, например, что довольно низкоуровневые инструменты, позволяющие работать с HTTP-протоколом, таят в себе подлянку в виде перетирания заранее заданного метода запроса.
"А расскажи про HTTP, REST, RESTful, про 7 принципов" — и не всегда понимаю, зачем. Ведь в реальности
А зачем про архитектуру Kafka, например? Кому из корпоративных программистов хоть раз надо было проектировать Кафку или что-то похожее? Обычно это несколько шаблонных строк для посылки или получения сообщения, и тебе уже говорят, что, как, куда и в каком виде надо принять или закинуть.
А зачем спрашивают про (подставить любой дурацкий вопрос)?
Ответ один. Жизнь это боль)
Адски плюсую
Чтобы шаблонные строки написать кто-то сначала должен написать шаблоны. Как без знания устройства кафки сделать сколь-либо надежный обмен сообщениями (приблизиться к пресловутому exactly-once), при этом не растеряв производительность? Как сделать месштабируемый сервис с ней? Куда бежать и на какие кнопки жать, если что-то пойдет не так, если сообщения иногда пропадают или консьюмеры постоянно падают?
1) шаблонные строки по чтению/записи пишутся тупо по руководству и примерам Кафки или вообще копируются с инета. 2) не надо путать дизайн и прикладной код, который и пишут программисты. Всё про exactly once или производительность, масштабируемость, что-угодно-ещё - это дело архитектора вместе с девопсами, ну ещё может быть, немного тимлида. Все остальные - просто делают так, как им говорят. Про кнопки жать - вообще не дело программиста (обычно), это к девопсам/SRE.
Кстати, аналогично с базами данных в больших проектах. Сколько раз обычный программист в жизни разработает структуру БД большого проекта? Ответ прост и однозначен - ни разу. Про кластеризацию и конкретную распределенную структуру вообще молчу. В больших серьёзных проектах не дадут даже минимальные изменения сделать, типа добавить поле или написать хранимую процедуру - все только через группу DBA.
С кафкой прикол в том, что половина её обвязки - ответственность клиентского кода, её подгоняют под конкретную ситуацию, вариаций порядочно. На каждой второй конференции будет часовой доклад про то, как у себя делали transactional outbox, какие ноги в процессе поотстреливали и к каким компромиссам в итоге пршли.
Инфраструктурный код пишут такие же программисты, а не мифические существа. Как правило, это та команда,которая первой столкнулась с необходимостью брокера на проекте. Возникающие проблемы приложения с ней решают тоже программисты, при необходимости привлекая девопсов и архитектора, если нужна донастройка со стороны эксплуатации или отеческое напутствие. И тут как с любым другим чужим кодом: чтобы его грамотно использовать важно знать его применимость и ограничения, а значит и устройство, хотя бы в общих чертах, включая саму кафку.
Значит, это маленький проект, иначе этим будет заниматься архитектор, техлид, тимлид, девопса и т.п., но только не программисты группы.
Если вся команда состоит из лида и толпы джуниоров - явно такие задачи будет тянуть только первый. Если же там сеньеры через одного - можно привлекать любого.
Что касается прочих - они код приложения не пишут.
Конечно, можно. И для этого можно много почитать и посмотреть уроков про Кафку, и все правильно сделать, даже если никогда не работал с ней. Но вопрос остаётся - как часто программист делает это реально? Мой ответ остаётся прежним - практически никогда.
Практически - не никогда, инфраструктурный код из воздуха не рождается. Отсюда возвращаемся бугурту в начале треда: при прочих равных выгоднее нанять программиста, который уже овладел необходимым, чем упереться в его "созревание", когда это таки понадобится.
Сколько раз требуется подключить Кафку с нуля, когда для этого нет архитектора или тимлида, или девопса, но есть деньги на новую должность сеньора? Раз в 10 лет? В 20? А сколько программистов сменится на проекте? Итого, какая вероятность для программиста, что сложатся в одно все эти факторы? Почти нулевая.
Архитектор или девопс вам кафку не подключат в приложение. Тимлид - это тоже программист. Но он и человек, который может заболеть или уволиться. Да и прочих дел у него хватает, нередко бывает так, что лиды сами код не пишут.
Да и на добавлении кафки приключения не заканчиваются - вокруг нее могут (да и будут, чего уж там) возникать разного рода проблемы, которые необходимо отлаживать. И, нет, архитектор с девопсом не полезут в код сервиса смотреть, по какой причине был отвал.
Ещё как полезут. И могут даже написать пример работающего кода. Вы вообще работали в больших проектах и конторах? Как будто на разных планетах.
У них других дел нет, чтобы еще и в программистов успевать играть?)
Самые разные конторы и проекты были. От типичного заказного бизнес-софта, до банковсковского энтерпрайза и бигтехов. И там бывали разные вариации деления ответственностью, но настолько программистов до писателей исключительно простого кода без обязанности принятия технических решений нигде не опускали)
Ну вообще конечно так и есть, что касается кафки у нас например полностью кастомный свой клиентский обвяз с transactional outbox, гибкой настройкой ретраев, отложенными отправками и так далее по списку. И подпиливать этот обвяз может каждый из команды, естественно с оглядкой на грейд, обсуждением с командой, плотным ревью и тестированием.
Что касается классических баз данных, по моему опыту изменение схемы, миграции данных, профилирование запросов с расставлены индексов и прочим - на плечах разрабатывающей фичу команды. При глобальных изменениях или когда изменения пересекаются несколькими командам - привлекается архитектор. Говорят, где-то бывают даже целые базисты (выделенные разработчики БД), но не встречал таких в живую. Масштабирование - да, работа в компании с DBA/девопсами, но инициатива и поддержка этого со стороны приложения - на команде разработки. Лид там представляет команду разработки или сеньеры, или все вместе (см. scrum) - это уже зависит от уровня команды и целевой автономности. Если вся команда состоит из лида и толпы джуниоров - явно такие задачи будет тянуть только первый. Если же там сеньеры через одного - можно привлекать любого.
"При тестировании с параметрами X, Y, заполненными значениями ... ожидали получить PDF-файл с стектрейсом, но не получили его. Просьба переделать согласно требований."
А что, принтеры так и делают. Когда у них прилетает "исключение", к примеру, из PostScript, они запросто совершенно могут постскриптовский стек вызовов распечатать на бумаге :)
А идея с CPU контролем вообще топ
Большая часть вполне нормальные кейсы. Понимаю тех кто так требовал.
Это просто нормально. Так куча систем работает. Клиент должен получить PDF, он только его принимать умеет. Значит или PDF или пятисотим если все сломалось. Пятисотить тоже лучше в PDF, но тут бывает всякое.
Открываем RFC. Не видим там запрета на русские буквы и просто реализуем.
Пишем легкую проксю которая перекладывает HTTP в сокет. Сам такие писал. Типовой случай.
Опять RFC позволяет. Надо и не противоречит RFC - значит делаем и не сопротивляемся.
Тоже просто нормально. Разные околоденежные системы так часто работают. Некафка, но идея похожая. Делаем очередь и спокойно работаем. Я делал подобное даже длиннее.
Идея топ. Надо красиво сделать и можно доедать все остатки ресурсов после другой более важной нагрузки. Все будет максимально быстро работать.
Дичь. Ну наконец то.
Нет, нормально это обработать правильно ошибку на вызывающей системе, а это однозначно вредный костыль. Все начинает осязаться когда пытаешься в логах понять какую ошибку отдал вызывающей системе, или pdf логать тоже просто нормально?) Или костыли в убер обвяз для логирования какието пилить, в общем ничего нормально не вижу.
Согл, но это в целом как-то неестественно, по этому немного коробит)
Да в целом это на прикладе реализуется довольно просто, прокся тут как будто лишнее усложнение которое нужно мониторить/саппортить/апдейтить/etc. Может в вашей сфере типовой, в моей за 7 лет один раз встретился, не типовой, экзотический и странный, почему не сделать по человечески, не понятно.
Ну мы и делаем да =)
Нет, не правильно, правильно стабилизировать/доработать вызывающую систему, а не размазывать ее логику по нескольким системам и потом дорабатывать/саппортить эту логику на нескольких.
Идея мягко говоря так себе, правильное решение здесь стабилизировать/доработать АБС, разделить нагрузку связанную с формированием отчетов и бух. проводок по разным нодам, добавить ресурсов в конце-концов. Еще тут есть своя специфика, ну например все проводки одного операционного дня нужно уложить в систему до закрытия этого дня, а если не уложил уже проблема и нужны доп манипуляции со стороны подразделений учета чтобы все правильно учесть. Соответственно нельзя не грузить проводки в систему по тому что кто-то где-то утилизирует ее формированием каких-либо отчетов, по этому решение не может выглядеть так, ну прям совсем, ибо создает проблем больше чем решает.
1 - Нормально да. Я тоже люблю хорошие и показательные графики кодов ответа. И сам так проектирую все. Но в реальном мире это совсем не редкость. Это скорее даже нормально для интеграций со всяким десктопом. И вообще не вызывает удивления.
3 - А надо делать так чтобы не ломалось. Делаем максимально дубовую проксю и разворачиваем в том же контейнере что и софтинка работающая по tcp. Чтобы сети между проксей и софтинкой не было. И никогда не трогаем. После этого все интеграции становятся понятными для типичного мидла, который про эти сокеты и знать не хочет и работать с ними не умеет. Я даже видел function-as-service по такой же схеме сделанную. И это было удобно.
5 - Это не всегда возможно и совсем не всегда рационально. Костылит тот кому проще костылить.
6 - я скорее про общий кейс. Есть гигантская система. В которую железо налить невозможно по объективным причинам. Таких систем много. Есть какая-то внешняя батчевая обработка использующая эту систему. Есть какая-то риалтайм нагрузка на ту же большую систему. Сделать так чтобы батчевая обработка доедала свободные от риалтайм нагрузки ресурсы это хороший план.
И через некоторое время... интеграция с... 1С.
Не KOI8R и ладно
Когда ТЗ — враг: 7 корпоративных запросов, над которыми плачут программисты