ну так в repl ее большую тоже не напишешь
ну сколько там? 300-400 строк

дальше голова поплывет

Зачем столько , мне кажется там пару строк юзают и всн

ну так для этого и скриптовый запуск вполне сгодится. Зачем дополнительный инструмент писать?

Привет!
Поделитесь, пожалуйста, опытом в таком вопросе:

Ситуация: есть микросервис, к которому обращаются все другие микросервисы. Этот микросервис в свою очередь стучит в third party API (TPA). TPA использует OAuth2/OIDC, тоесть наш микросервис должен иметь access token, чтобы стучать в ТРА, и refresh token, чтобы получать новый access token.

Проблема: как правильно хранить и рефрешить access token в многопоточной среде с несколькими инстансами нашего микросервиса, когда TPA разрешает иметь только 1 валидный access token в единицу времени? Может есть какие-то best practices в этом плане.

Потенциальное решение: хранить в relational DB (к примеру, PostgreSQL) и реализовать locking на уровне кода через Pessimistic lock.
Проблема решения: мне кажется, что это немного overhead поднимать реляционную базу, чтобы хранить всего 2 объекта (access and refresh tokens), по-этому хотелось бы что-то проще и шустрее (Redis / Memcached), но там с локами не все так тривиально - не уверен, что создавать distributed lock в том же Redis-е - это хорошее решение.

Подскажите, пожалуйста, ваши best practices в этом плане. Спасибо!

а лок зачем хочется иметь?

для такой ситуации:
1-ый поток считал токен и хочет использовать его, чтобы стучать в third party, но между этими 2-мя событиями 2-ой поток зарефрешил этот токен и сделал недействительным. 1-ый поток получает 401/403.

Или такая еще ситуация: несколько потоков одновременно заметили, что токен заэкспайрился, и каждый пошел его рефрешить.

ага, окей, и это плохо по какой-то причине? Ну, то есть, если токен живет минут 10, например, то самое худшее, что может случится - несколько раз получим одновременно новый токен

мне кажется, что тут может начаться гонка по кругу: поток рефрешит токен -> стучит в third party -> получает 401/403 (ведь другой поток уже зарефрешил тоже) -> retry. Не совсем понятно, как грамотно выйти с этого цикла.

а мы знаем, сколько живет наш токен? Если знаем, что он живет, например, 10 минут, то можно каждые 9 минут обновлять его в фоне

об этом тоже думал, была идея сделать отдельную AWS Lambda, чтобы не думать, как синхронизировать scheduler-ы между инстансами.
Проблемы:
- если third party изменит длительность жизни токена (особенно в сторону уменьшения), надо это вовремя заметить
- мне не совсем нравится подход написания бесконечного retry-я в scheduler-е (тоесть, если OIDC third party сервер временно упал, а у нас недействительный токен, то надо стучать туда вечно, пока сервер не подымется).

капец жёстко) ради обновления токена aws лямбды делать))

а это не jwt?
токен как-то инвалидируется с той стороны и только один валидный?

да, только один валидный в один момент времени. Там вроде не JWT, а просто набор символов, но надо точно проверить.

да вот и мне кажется, что это довольно тривиальная задача, а я не могу найти какое-то оптимальное решение =)

блин, так получается их токен это тупо строка
и даже не получится его время жизни узнать?

я думал что все уже юзают jwt)

А он что, такой ультимативный? Лично я считаю его неудобным

получится, токен прилетает в таком JSON:

{
    …
    “access_token”: “aaaaaavvvvbbbb”,
    “expires_in”: “42”
    …
}

По поводу JWT: даже если был бы JWT, но один только валидный в текущий момент, задача то не изменилась бы.