Как стать автором
Обновить
2
0

Пользователь

Отправить сообщение

Есть БД, которые умеют хранить время с регионом таймзоны в одном поле?

Это просто опыт.

Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.

А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.

И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.

даже больше скажу.

утверждение: "всегда хранить время 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, хоть любой прочий) - очень хорошая практика.

Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.

Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.

Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.

С этим согласен

  • Хоть номинально все RPC вызовы и проходят через один Temporal кластер, но гибких возможностей выстраивать политику кто и что может, вроде как, нельзя. Поэтому сервисы практически бесконтрольно могут дёргать друг-друга.

Странный тезис.

Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.

Аналогично.

Любые сигнатуры - это API. Что внешний API (например REST), что внутренний API (например IoC) налагают требования по контролю целостности API со стороны консьюмера и провайдера. Темпорал в этом плане ничего нового не привносит.

  • Оверхед на код — придётся писать больше кода, но во времена copilot-а это не такая уж и серьезная проблема.

Оверхед по сравнению с совсем простым кодом - без перевызова, без таймаутов, без альтернативных сценариев, без ролбеков.

А если сравнивать код со всем этим, в двух реализациях - с темпорал и без, то код с темпорал существенно меньше.

В целом, Temporal - must have инструмент, в микросервисной архитектуре.

откуда вывод, что websocket для не больших сообщений? практика говорит, что и большие бинарные файлы можно передавать. а текстовые тем более

скажем, эффект от использования вебсокетов больше, когда взаимодействие построено на большом количестве мелких запросов/ответов.

на любую здравую идею можно найти исключение.

это не делает идею менее здравой.

Создавать proto-файлы в обычном java-проекте - это хорошо.

А если ли инструменты, позволяющие безболезненно импортировать и обновлять proto-файлы из типичных golang-проектов? Типичных golang - имеется ввиду тех, которые добавляются в качестве golang-зависимостей к golang проекту

а я не буду никого защищать ;)

буду просто использовать инструменты по назначению, иногда статическая типизация рулит, иногда динамическая.

хорошо же, когда есть выбор, и понимание сильных и слабых сторон инструментов

Почему BRE, а не CEP (Complex Event Processing)?

зачем админку убираем с публичного домена - понимаю.
зачем админку убираем совсем с ингресс-контроллера - не понимаю.

ну да ладно...

а повесить админку на отдельный ингресс или игресс-контроллер?

Информация

В рейтинге
5 070-й
Зарегистрирован
Активность