Хорошо, вы помните откуда взялась ваша мотивация? Не из вакуума же? У вас были родители, окружение, общество, государство — они прививали вам определённые ценности. Быть умным — котировалось, а сейчас больше котируется быть быстрым, предприимчивым и богатым. Если хочется развернуть эту реку вспять, то нужно снова раскручивать «культ сильного ума». Как? Хз. Но точно не приказами "учитесь и разбирайтесь".
Ох :) Какой нервный текст с нотками самолюбования и графомании ;)
Дааа... в наше-то время на асемблере писали, а сейчас эх.. молодежь пошла... поначитаются про микросервисы и комитят друг-другу в монорепы.
С «молодежью» нужно уметь работать. И нет, сказать "учитесь" и "разберитесь" — не выйдет. Нужно заинтересовать, а ныть про времена, нравы и религию хз зачем. Как это поможет?
По сравнению с REST и GQL, которым мы пользуемся сейчас, Temporal работает без схемы (OpenAPI, GQL и т.п.) поэтому следить за контрактами будет сложнее. Наверное так можно переформулировать "минус" про сигнатуры.
Что мешает передавать в аргументах любую авторизационную информацию и проверять ее в провайдерах? В случае ошибки - бросать Non retryable exception.
В провайдерах проверять — можно. Я имел ввиду, что нет общего компонента, который бы авторизовывал вызовы между сервисами на основе заголовков/директив и т.п.
Основная сложность в том, что у нас уже есть компонент, через который проходит весь трафик — единое API, на нём мы и отслеживаем выполнение разных политик. Добавляя Temporal, мы получаем второй компонент, хотя, наверное, можно придумать как пропускать Temporal трафик через единое API.
Спасибо за идею ) А где у вас лежат эти трейты? Все вместе в одном неймспейсе или раскиданы по кодовой базе? Как разработчики ищут activity, чтобы случайно не написать уже существующий?
Спасибо! Очень похоже на архитектуру, которую я планировал изначально, но перед внедрением решил сделать ещё круг и потестить https://temporal.io/ — выглядит очень интересно, на след неделе опубликую статью.
Транзакция здесь — не способ построения, а абстракция от реального бизнес-процесса покупка->товар, например. Без транзакции ты физически можешь потерять данные о покупке или товаре и тогда никакие кеши тебя не спасут— спасёт только философия :) Типа, извини, друг, не повезло — потеряли мы твой "товар" и это есть суть вещей. Низведём же в конструкте человеческого сознания страх потери!
Руками только тулинг настраивать в идеале, а все остальные навыки нужны для грамотного менеджмента.
Хорошо, вы помните откуда взялась ваша мотивация? Не из вакуума же? У вас были родители, окружение, общество, государство — они прививали вам определённые ценности. Быть умным — котировалось, а сейчас больше котируется быть быстрым, предприимчивым и богатым. Если хочется развернуть эту реку вспять, то нужно снова раскручивать «культ сильного ума». Как? Хз. Но точно не приказами "учитесь и разбирайтесь".
Ох :) Какой нервный текст с нотками самолюбования и графомании ;)
Дааа... в наше-то время на асемблере писали, а сейчас эх.. молодежь пошла... поначитаются про микросервисы и комитят друг-другу в монорепы.
С «молодежью» нужно уметь работать. И нет, сказать "учитесь" и "разберитесь" — не выйдет. Нужно заинтересовать, а ныть про времена, нравы и религию хз зачем. Как это поможет?
Избранное (в нижнем меню) -> Учить слова
Приложение "Яндекс Переводчик" позволяет переводить и учить слова методом интервальных повторений.
Не очень понял что такое "переход на protobuf" в контексте решение проблемы отсутствия схемы у Temporal.
По сравнению с REST и GQL, которым мы пользуемся сейчас, Temporal работает без схемы (OpenAPI, GQL и т.п.) поэтому следить за контрактами будет сложнее. Наверное так можно переформулировать "минус" про сигнатуры.
В провайдерах проверять — можно. Я имел ввиду, что нет общего компонента, который бы авторизовывал вызовы между сервисами на основе заголовков/директив и т.п.
О, это интересно, спасибо!
У нас TypeScript, PHP и ещё немного Python. П
Основная сложность в том, что у нас уже есть компонент, через который проходит весь трафик — единое API, на нём мы и отслеживаем выполнение разных политик. Добавляя Temporal, мы получаем второй компонент, хотя, наверное, можно придумать как пропускать Temporal трафик через единое API.
Спасибо за идею )
А где у вас лежат эти трейты? Все вместе в одном неймспейсе или раскиданы по кодовой базе? Как разработчики ищут activity, чтобы случайно не написать уже существующий?
А как конкретно это выглядит? В виде кода? Какая-то декларативная форма?
Спасибо! Очень похоже на архитектуру, которую я планировал изначально, но перед внедрением решил сделать ещё круг и потестить https://temporal.io/ — выглядит очень интересно, на след неделе опубликую статью.
Как разработчики пишут транзакции? Какой-то DSL используют? В виде обычного SQL, но 2PC разруливает какой-то прокси?
На какие компромиссы пришлось пойти?
Примерно с какой нагрузкой и каким объёмом данных вы работаете?
Транзакция здесь — не способ построения, а абстракция от реального бизнес-процесса покупка->товар, например. Без транзакции ты физически можешь потерять данные о покупке или товаре и тогда никакие кеши тебя не спасут— спасёт только философия :) Типа, извини, друг, не повезло — потеряли мы твой "товар" и это есть суть вещей. Низведём же в конструкте человеческого сознания страх потери!
Было бы интересно почитать подробности :) Обычно же как раз не советуют использовать 2PC.