"Зачем Flux<ResponseKeycloak> для ОДНОГО токена? Mono вроде бы просится сам собой. " - Да, так тоже можно, но я предпочел Flux. Чисто субъективно ) Не увидел в нем минусов по сравнению с Mono. Тут именно просто "предпочел".
"Mono.create вероятно прячется block() " - В create как раз нет. Если бы использовал работу с контекстом, то там он "прятался".
"Retry.fixedDelay(2, …) против MAX_ALLOWED_RETRIES = 3 — какая цифра правит бал? я, честно, запутался " - MAX_ALLOWED_RETRIES. Видимо я немного путанно написал. Позже поправлю.
"@CacheEvict на каждый ретрай может устроить набег на Keycloak при высокой нагрузке, было бы классно подстраховаться чем-то вроде CacheMono." - мысль понял. При написании кода руководствовался тем, что Keycloak такие набеги вывозил. Мысль Ваша интересная. Подумаю, поправлю.
"Сырые Map<String,String> вместо DTO — да, гибко, но типобезопасность улетела, ловим опечатки уже на проде " - руководствовался устоявшимся конктрактом. Типобезопасность улетела. Ваша правда.
"1. Рассматривали WebClient + OAuth2AuthorizedClientManager, почему выбрали свой велосипед? " - Рассматривали. Это вариант был менее производительным при замерах. Про выбор технологий была предыдущая статья, но там нет конкретных замеров. В моем случае предлагаемая Вами связка была на 20% менее производительной.
"Токен кешируется, ок. А защита от dog-pile-эффекта есть? Типа “де-дуп” запросов пока первый ещё не вернулся." - нет, этого не предусмотрел. Вопрос очень интересный. Думаю под это можно будет отдельную статью написать.
"Всё-таки Flux — может есть кейс, где приходит пачка токенов? незнаю, интересно." - пока такого нет, но есть идеи о том, где может возникнуть. Но эти идеи пока сырые с моей стороны. Тут делиться пока нечем.
О том, что надо "вдумчиво" использовать тот же Agile Manifesto? О том, что в рамках Agile можно собираться на Retro и баланс будет соблюден? О том, что в Kanban есть аж 2 каденции направленные на соблюдение этого баланса? Или о том, что можно путать людей, которые не разбираются в Agile и Kanban, отражением только части картины?
1) Кроме увеличения скорости обработки есть ещё плюс в увеличении объемов запросов. Для нас переход абсолютно оправдан. Каких-то критичных сложностей для себя мы пока не нашли.
2) Пока нет. Спасибо за информацию. Попробуем в ближайшее время )
Реальные замеры с/без Кеша, замеры количества вызовов сторонней системы и юнит тесты подтверждают, что аннотация работает так, как изложено в статье. Но я перепроверю. Если будут расхождения, то вернусь с правками )
Здраствуйте, Не смогу порассуждать/обсудить тему. Что такое Зиккурат не знаю, гуглинг по этому названию не предложил систему, которая бы соответствовала IAM системам. Приложите ссылку, пожалуйста, на материал. Посмотрю позже.
Если правильно понял, вопрос, то Вы больше про авторизацию - права на конкретные действия, конкретных пользователей или групп. При том, что еще в конктексте вопроса связь с БД. Предполагаю, должен быть какой-то процесс, в ходе которого будет понятно, кто пришел извне и какие у него права на работу с БД (просмотр/изменение/удаление). Видимо надо понять, кто это пришел, связать его с пользователем БД, который однозначно определит - есть ли у этого право что-то сделать/увидеть или нет.
Keycloak поможет связать это все в конкретное действие, то есть для пользователя определить права (в админке, сторонней таблице и т.д.). Flow остается таким же, как описано выше. Вы просто переложили заботу о правах и возможностях пользователя на отдельную систему, которая предоставит результат аудита прав этого пользователя.
Вы выполните действия, получите ответ и транслируете его в сервис. Если этого не делать, то, все действия рассредоточятся по нескольким системам. Это усложнит поддержку и развитие процесса.
Кратко так. Надеюсь правильно понял и корректно ответил на вопрос.
Синтаксис Rest assured для того, кто будет поддерживать тесты был более понятен. WebTestClient подробно не смотрел. Спасибо за информацию. Посмотрю подробнее.
Здраствуйте, чтобы ответить на Ваш вопрос надо сделать небольшой рефрен в сторону того, как осуществляется сетевой обмен и что такое сетевая устойчивость, ориентированная на обработку статусов http. Шаблоны поддержки сетевой устойчивости предполагают, что Вы установили соединение по url и с отвечающий стороны есть компонент, который орбрабатывает Ваши соединения. Если компоненты (nginx/tomcat/...), обрабатывающей Ваши запросы нет, то Вам и отвечать некому. Это можно воспроизвести с помощью вызова через любой доступный инструмент curl/postman/insonmnia/... по произвольному адресу, произвольного запроса. Если же Вы находитесь в экзотической ситуации, и соединение то есть, то его просто нет (исчез/удален/перемещен), но при этом Вы уверены в том, что он там должен быть/появится, то попробуйте обработать свой вызов через ->
...
try
{вызов ресурса}
catch
(отлов ошибки)
{логика повторных вызовов}
...
Чего-то более интеллектуального по тому контексту, что Вы написали и предложить/подсказать не могу )
Вам нужны критерии классификации. Этой статьёй я не брал себе задачу определить и вынести критерии выделения каждого типа анализа в отдельную сферу деятельности. Для этого мне нужно было продублировать и адаптировать информацию из приложенных ссылок. Это, наверное, другая, более теоретическая статья.
Я взял себе задачей показать, для каких задач и в каком контексте следует применить каждый из них. Дать рекомендации, сделать короткие заключения о том, что и когда использовать.
Конечно. Абзац "Типы анализа ...", по каждому типу анализа дана ссылочка на best practice. Если требуется, то могу дать ссылки на конкретные программы )
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.
Здраствуйте, к сожалению нет.
Подобное предложение я разбирал в комментариях к одной из прошлых статей - https://habr.com/ru/companies/alfastrah/articles/856856/#comment_27529680
То, что Вы предлагаете - создает аутентификацию.
Сервис, предлагает способ пройти аутентификацию.
Или я неправильно понял Вашу мысль.
Здраствуйте,
"Зачем Flux<ResponseKeycloak> для ОДНОГО токена? Mono вроде бы просится сам собой. " - Да, так тоже можно, но я предпочел Flux. Чисто субъективно ) Не увидел в нем минусов по сравнению с Mono. Тут именно просто "предпочел".
"Mono.create вероятно прячется block() " - В create как раз нет. Если бы использовал работу с контекстом, то там он "прятался".
"Retry.fixedDelay(2, …) против MAX_ALLOWED_RETRIES = 3 — какая цифра правит бал? я, честно, запутался " - MAX_ALLOWED_RETRIES. Видимо я немного путанно написал. Позже поправлю.
"@CacheEvict на каждый ретрай может устроить набег на Keycloak при высокой нагрузке, было бы классно подстраховаться чем-то вроде CacheMono." - мысль понял. При написании кода руководствовался тем, что Keycloak такие набеги вывозил. Мысль Ваша интересная. Подумаю, поправлю.
"Сырые Map<String,String> вместо DTO — да, гибко, но типобезопасность улетела, ловим опечатки уже на проде " - руководствовался устоявшимся конктрактом. Типобезопасность улетела. Ваша правда.
"1. Рассматривали WebClient + OAuth2AuthorizedClientManager, почему выбрали свой велосипед? " - Рассматривали. Это вариант был менее производительным при замерах. Про выбор технологий была предыдущая статья, но там нет конкретных замеров. В моем случае предлагаемая Вами связка была на 20% менее производительной.
"Токен кешируется, ок. А защита от dog-pile-эффекта есть? Типа “де-дуп” запросов пока первый ещё не вернулся." - нет, этого не предусмотрел. Вопрос очень интересный. Думаю под это можно будет отдельную статью написать.
"Всё-таки Flux — может есть кейс, где приходит пачка токенов? незнаю, интересно." - пока такого нет, но есть идеи о том, где может возникнуть. Но эти идеи пока сырые с моей стороны. Тут делиться пока нечем.
Появится компетенция в этом вопросе - обязательно расскажу )
О чем эта статья?
О том, что надо "вдумчиво" использовать тот же Agile Manifesto?
О том, что в рамках Agile можно собираться на Retro и баланс будет соблюден?
О том, что в Kanban есть аж 2 каденции направленные на соблюдение этого баланса?
Или о том, что можно путать людей, которые не разбираются в Agile и Kanban, отражением только части картины?
Здравствуйте,
1) Кроме увеличения скорости обработки есть ещё плюс в увеличении объемов запросов. Для нас переход абсолютно оправдан. Каких-то критичных сложностей для себя мы пока не нашли.
2) Пока нет. Спасибо за информацию. Попробуем в ближайшее время )
Реальные замеры с/без Кеша, замеры количества вызовов сторонней системы и юнит тесты подтверждают, что аннотация работает так, как изложено в статье. Но я перепроверю. Если будут расхождения, то вернусь с правками )
Ну может для Ваших версий было и не зря )
Как минимум навык наработали )
Плюс в карму для опыты )
Здраствуйте,
У реактивного сервиса актуальный pom такой - https://github.com/engine-it-in/service-reactor/blob/main/pom.xml
spring-boot-starter-parent -> 3.4.2
com.playtika.reactivefeign -> 4.2.1
Может быть ранее они были не совместимы. На тех версиях, что я указал все работает
Здраствуйте,
Не смогу порассуждать/обсудить тему. Что такое Зиккурат не знаю, гуглинг по этому названию не предложил систему, которая бы соответствовала IAM системам. Приложите ссылку, пожалуйста, на материал. Посмотрю позже.
Если правильно понял, вопрос, то Вы больше про авторизацию - права на конкретные действия, конкретных пользователей или групп. При том, что еще в конктексте вопроса связь с БД. Предполагаю, должен быть какой-то процесс, в ходе которого будет понятно, кто пришел извне и какие у него права на работу с БД (просмотр/изменение/удаление). Видимо надо понять, кто это пришел, связать его с пользователем БД, который однозначно определит - есть ли у этого право что-то сделать/увидеть или нет.
Keycloak поможет связать это все в конкретное действие, то есть для пользователя определить права (в админке, сторонней таблице и т.д.). Flow остается таким же, как описано выше. Вы просто переложили заботу о правах и возможностях пользователя на отдельную систему, которая предоставит результат аудита прав этого пользователя.
Вы выполните действия, получите ответ и транслируете его в сервис. Если этого не делать, то, все действия рассредоточятся по нескольким системам. Это усложнит поддержку и развитие процесса.
Кратко так. Надеюсь правильно понял и корректно ответил на вопрос.
Здраствуйте,
Из того, ссылку на что Вы прислали
Spring Security supports protecting endpoints by using two forms of OAuth 2.0 Bearer TokensЧто в переводе
Spring Security поддерживает защиту конечных точек с помощью двух форм токенов OAuth 2.0 Bearer TokensТо есть стандартный starter реализует защиту, а в компоненте/статье я показываю способ преодолеть защиту )
Стартером, ссылку на который Вы дали, мы пользуемся.
Не знал/не нашел про этот инструмент для JMeter. Спасибо за информацию.
Автор - спасибо тебе большое )
Целую твой лоб и желание сделать перевод. Чего-то подобного в рускоязычном сегменте интернета не так много.
Отлично. Пусть принесет Вам пользу )
Синтаксис Rest assured для того, кто будет поддерживать тесты был более понятен. WebTestClient подробно не смотрел. Спасибо за информацию. Посмотрю подробнее.
Спасибо большое. Поправлю.
Здраствуйте, чтобы ответить на Ваш вопрос надо сделать небольшой рефрен в сторону того, как осуществляется сетевой обмен и что такое сетевая устойчивость, ориентированная на обработку статусов http.
Шаблоны поддержки сетевой устойчивости предполагают, что Вы установили соединение по url и с отвечающий стороны есть компонент, который орбрабатывает Ваши соединения. Если компоненты (nginx/tomcat/...), обрабатывающей Ваши запросы нет, то Вам и отвечать некому. Это можно воспроизвести с помощью вызова через любой доступный инструмент curl/postman/insonmnia/... по произвольному адресу, произвольного запроса.
Если же Вы находитесь в экзотической ситуации, и соединение то есть, то его просто нет (исчез/удален/перемещен), но при этом Вы уверены в том, что он там должен быть/появится, то попробуйте обработать свой вызов через ->
...
try{вызов ресурса}catch(отлов ошибки){логика повторных вызовов}...Чего-то более интеллектуального по тому контексту, что Вы написали и предложить/подсказать не могу )
Крутая статья, крутая работа.
Понятно. Спасибо.
Вам нужны критерии классификации. Этой статьёй я не брал себе задачу определить и вынести критерии выделения каждого типа анализа в отдельную сферу деятельности. Для этого мне нужно было продублировать и адаптировать информацию из приложенных ссылок. Это, наверное, другая, более теоретическая статья.
Я взял себе задачей показать, для каких задач и в каком контексте следует применить каждый из них. Дать рекомендации, сделать короткие заключения о том, что и когда использовать.
Исходя из Вашей обратной связи, это получилось.
Спасибо за мнение.
Конечно. Абзац "Типы анализа ...", по каждому типу анализа дана ссылочка на best practice. Если требуется, то могу дать ссылки на конкретные программы )
Спасибо за вопрос. Хочу обратить внимание, что данная типология не мое умозаключение. Это устоявшаяся классификация типов анализа. У каждого из них есть комьюнити, учебные программы, специальности, на которых учат на курсах и в Высших учебных заведениях. Типология есть и она определяется объектом воздействия, точкой приложения анализа. Перефразировать = заниматься графоманией. Есть специальности, есть штатные единицы в компании на которых берут системных аналитиков ( есть стандарт на данный вид деятельности, который выражен типом анализа ), бизнес аналитиков, процессных аналитиков и аналитиков данных. Можно открыть hh/ хабр карьера и по точному соответствию специальности найти конкретные вакансии.
По поводу спирали, этапов работ - понял, мысль по поводу цикличности и востребованности всех типов анализа в зависимости от развитости конкретного организационного контекста я, значит не раскрыл на столько, чтобы она была очевидна. Предполагаю, что не хватило именно иллюстрации спиральности. Добавлю.