В докладе вскользь упомянули, про то, что не нужно вызывать метод values у перечислений. Оказывается, там очень интересная магия скрыта под капотом. Есть описание в частности в статье на Хабре "Загадки Enum'ов". Но приведённое в данном ролике решение, как-то замерялось на производительность? А то про values в докладе упомянули и это хорошо, а вот насколько "тяжелее" могло или не могло стать данное решение для приложения? Также в комментариях ниже упоминали, про опасность складывать любое "неизвестное" значение в Map'у, т.к. может потенциально стать вектором атаки злоумышленника.
Интересный подход, но его использование может привести к отказу всей цепочки микросервисов, работающий на «платформа», когда злоумышленник начнет посылать сообщения с уникальными строками вместо enum. Мапа будет разрастаться, и oom не заставит себя ждать. Можно на weak мапе сделать то же самое, но с защитой от oom. Однако, дедупликация делается только ради использования “==“ вместо “equals” при сравнении объектов (не enum констант), что кажется довольно сомнительной затеей.
@@kirillsh8383 Именно ситуацию с unknown мы проговорили. Если микросервис как-то использует enum для логики, то unknown хорошо работает, потому что логика должна понимать, что пришло что-то неожиданное. Но нередко вот эти значения, пришедшие снаружи, нужно просто передать по цепочке в другой микросервис и тогда unknown приводит к потере данных.
Enum ни в чём не виноват, просто Enum плохо подходят для решний с микросервисным API. Так то конечно удобнее сделать монолит. Но мы как раз о том случает, когда микросервисы уже данность.
в случаее изменении в либс. надо деплоить все микросервисы у которых есть зависимость от него, если у вас это 3-5 микросервисы - нормально, если 10-50 - > зовите нового Архитектора . Если у вас зависимость - значет у Вас бизнес контекст в нескольких сервисах - а вы хотите деплоить только один ....
В докладе вскользь упомянули, про то, что не нужно вызывать метод values у перечислений. Оказывается, там очень интересная магия скрыта под капотом. Есть описание в частности в статье на Хабре "Загадки Enum'ов". Но приведённое в данном ролике решение, как-то замерялось на производительность? А то про values в докладе упомянули и это хорошо, а вот насколько "тяжелее" могло или не могло стать данное решение для приложения? Также в комментариях ниже упоминали, про опасность складывать любое "неизвестное" значение в Map'у, т.к. может потенциально стать вектором атаки злоумышленника.
Крутой доклад! сейчас у нас такая же проблема попробую ее решить этим способом, спасибо!
Интересный подход, но его использование может привести к отказу всей цепочки микросервисов, работающий на «платформа», когда злоумышленник начнет посылать сообщения с уникальными строками вместо enum. Мапа будет разрастаться, и oom не заставит себя ждать. Можно на weak мапе сделать то же самое, но с защитой от oom.
Однако, дедупликация делается только ради использования “==“ вместо “equals” при сравнении объектов (не enum констант), что кажется довольно сомнительной затеей.
Мы напилили "микросервисов", а теперь из-за Enum нам надо в них во все вносить изменения. Ну да, виноват Enum)
@@kirillsh8383 Именно ситуацию с unknown мы проговорили. Если микросервис как-то использует enum для логики, то unknown хорошо работает, потому что логика должна понимать, что пришло что-то неожиданное. Но нередко вот эти значения, пришедшие снаружи, нужно просто передать по цепочке в другой микросервис и тогда unknown приводит к потере данных.
Enum ни в чём не виноват, просто Enum плохо подходят для решний с микросервисным API. Так то конечно удобнее сделать монолит. Но мы как раз о том случает, когда микросервисы уже данность.
в случаее изменении в либс. надо деплоить все микросервисы у которых есть зависимость от него, если у вас это 3-5 микросервисы - нормально, если 10-50 - > зовите нового Архитектора . Если у вас зависимость - значет у Вас бизнес контекст в нескольких сервисах - а вы хотите деплоить только один ....
Интереснее получится, когда Enum передается не в составе какой-нибудь dto-хи сразу в query-param и вредный пользователь ввел несуществующее значение.
"Общая библиотека в микросервисах..." Красивое.
Будет ли spring boot starter?
Кто-то платил за это)
проблема явно не в енаме, а в том, что все зависят от некой платформы, причем сильно.
Руками править версию платформы? Так реально кто-то делает?
Я не удивлюсь, если так делает большинство небольших компаний. Или стартапов. Увы.