Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с 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 проекту
В целом с большинством тезисов согласен.
Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
Свои сборки jdk есть у многих крупных компаний Китая и Европы.
И не только jdk.
Camunda 8-й версии научилась "из коробки" не выпадать в осадок, если вызываемые синхронные сервисы замедлились или таймаутят?
GraphQL окупается в случае:
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Есть БД, которые умеют хранить время с регионом таймзоны в одном поле?
Это просто опыт.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
даже больше скажу.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
А почему бы не дать имя тесту как "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 проекту
а я не буду никого защищать ;)
буду просто использовать инструменты по назначению, иногда статическая типизация рулит, иногда динамическая.
хорошо же, когда есть выбор, и понимание сильных и слабых сторон инструментов