Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с Hb или без
По опыту, наблюдая проекты в которых API Gateway запилен на базе java-фреймворков, пришел для себя к предположению, что выбор решения был за чуваками, шарящими в java, но не шарящими чуть в сторону.
Это не хорошо, не плохо. Просто наблюдение. Нельзя шарить везде и во всем. А других шарящих чуваков в команде не оказалось.
В требованиях только вот это "Гейтвей должен маршрутизировать запросы в сервисы разных версий в зависимости от версии клиентского приложения" относительно нетривиально. Остальное штатным готовым API Gateway'ем решается.
Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.
Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.
Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.
Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.
Странный тезис.
Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.
Любые сигнатуры - это API. Что внешний API (например REST), что внутренний API (например IoC) налагают требования по контролю целостности API со стороны консьюмера и провайдера. Темпорал в этом плане ничего нового не привносит.
Оверхед на код — придётся писать больше кода, но во времена copilot-а это не такая уж и серьезная проблема.
Оверхед по сравнению с совсем простым кодом - без перевызова, без таймаутов, без альтернативных сценариев, без ролбеков.
А если сравнивать код со всем этим, в двух реализациях - с темпорал и без, то код с темпорал существенно меньше.
В целом, Temporal - must have инструмент, в микросервисной архитектуре.
Создавать proto-файлы в обычном java-проекте - это хорошо.
А если ли инструменты, позволяющие безболезненно импортировать и обновлять proto-файлы из типичных golang-проектов? Типичных golang - имеется ввиду тех, которые добавляются в качестве golang-зависимостей к golang проекту
Зависит от команды. Если команда согласна на 172 символа - вперед.
У нас в команде есть пользователи, любящие и умеющие эффективно работать на мелких ноутах. Для них ограничение в 72 символа - очень важно.
Для себя лично пришел к выводу: мне может и не важно ограничение в 72 символа, но придерживаться почти ничего не стоит. И кто и когда будет листать этот репозитарий, я не знаю, поэтому на всякий случай лучше придерживаться рекомендаций, в том числе и на длину строки, чтобы им было приятно.
А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.
Это абсолютно справедливо. Для любого инструмента.
Одно из главных правил Agile-методологий – команда-исполнитель принимает от заказчика изменения/ дополнения на любой стадии проекта.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.
А почему бы не дать имя тесту как "Calculator's listSum should return 5"?
наверно потому что runas плохо дружит со скриптами
Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с Hb или без
По опыту, наблюдая проекты в которых API Gateway запилен на базе java-фреймворков, пришел для себя к предположению, что выбор решения был за чуваками, шарящими в java, но не шарящими чуть в сторону.
Это не хорошо, не плохо. Просто наблюдение. Нельзя шарить везде и во всем. А других шарящих чуваков в команде не оказалось.
В требованиях только вот это "Гейтвей должен маршрутизировать запросы в сервисы разных версий в зависимости от версии клиентского приложения" относительно нетривиально. Остальное штатным готовым API Gateway'ем решается.
Публикация джарок, сгенеренных с proto-файлов - понятно.
А вы делали публикацию/импорт самих proto-файлов из java/kotlin проектов? Protobuf - он же как бы мультиплатформенный.
По моему когда очень длинный флоу, то ни визуально, ни ...-as-code переварить очень сложно.
И спасает только декомпозиция.
А в целом, представлять флоу в виде человеко-ориентированного DSL (неважно какого, хоть Kotlin DSL, хоть любой прочий) - очень хорошая практика.
Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.
Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.
Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.
С этим согласен
Странный тезис.
Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.
Аналогично.
Любые сигнатуры - это API. Что внешний API (например REST), что внутренний API (например IoC) налагают требования по контролю целостности API со стороны консьюмера и провайдера. Темпорал в этом плане ничего нового не привносит.
Оверхед по сравнению с совсем простым кодом - без перевызова, без таймаутов, без альтернативных сценариев, без ролбеков.
А если сравнивать код со всем этим, в двух реализациях - с темпорал и без, то код с темпорал существенно меньше.
В целом, Temporal - must have инструмент, в микросервисной архитектуре.
скажем, эффект от использования вебсокетов больше, когда взаимодействие построено на большом количестве мелких запросов/ответов.
на любую здравую идею можно найти исключение.
это не делает идею менее здравой.
Создавать proto-файлы в обычном java-проекте - это хорошо.
А если ли инструменты, позволяющие безболезненно импортировать и обновлять proto-файлы из типичных golang-проектов? Типичных golang - имеется ввиду тех, которые добавляются в качестве golang-зависимостей к golang проекту
а я не буду никого защищать ;)
буду просто использовать инструменты по назначению, иногда статическая типизация рулит, иногда динамическая.
хорошо же, когда есть выбор, и понимание сильных и слабых сторон инструментов
Почему BRE, а не CEP (Complex Event Processing)?
зачем админку убираем с публичного домена - понимаю.
зачем админку убираем совсем с ингресс-контроллера - не понимаю.
ну да ладно...
а повесить админку на отдельный ингресс или игресс-контроллер?
https://dubbo.apache.org/
Зависит от команды. Если команда согласна на 172 символа - вперед.
У нас в команде есть пользователи, любящие и умеющие эффективно работать на мелких ноутах. Для них ограничение в 72 символа - очень важно.
Для себя лично пришел к выводу: мне может и не важно ограничение в 72 символа, но придерживаться почти ничего не стоит. И кто и когда будет листать этот репозитарий, я не знаю, поэтому на всякий случай лучше придерживаться рекомендаций, в том числе и на длину строки, чтобы им было приятно.
Это абсолютно справедливо. Для любого инструмента.
Неверное заблуждение.
Agile - не про покорность исполнителя, и прием любых изменений в любое время.
Agile - про отсутствие деления на исполнителя и заказчика. Есть команда, ответственная за результат. И лицо, принимающее ключевые решение по свойствам продукта, такой же член команды, как и все остальные.
И главный критерий использования Agile-подхода - это не простота или сложность проекта. А возможность коротких итераций для выпуска новых версий продукта. Можете выкатывать в продажу чайник новой версии каждые 1-4 недели, флаг Agile'а вам в руки. Не можете - вам Agile не нужен.
И изменение приоритетов и переобувание по фичам продукта происходит как раз между итерациями. Их так и называют "спринт" - короткий забег на заранее определенную дистанцию. Потом остановка, определение нового направления и дистанции, и новый короткий забег. Во время забега, понятно, не до изменения требований, надо просто бежать.
Аналогии производства ПО и материальных объектов, действительно, уместны. Но ограничено.
Разница как раз в материальности объектов. На условном заводе новую деталь можно начать испытывать только после ее изготовления, а это всегда некоторый срок. На условном сервере, новый код можно начать испытывать условно через пару минут после пуша.
Что будет если испытания прошли неудачно? С деталькой - надо будет делать новую версию, а это опять некоторый срок. С кодом - в общем случае через пару минут можешь запушить новую версию.
И это разница в подходах - фундаментально влияет на организацию труда.
Понятно, что всегда можно придумать пограничные случаи, когда новую версию кода выпускают раз в несколько дней, а детальки печатают за несколько минут. Но то исключения, а не правило.