Илья Сазонов, Федор Сазонов - Enum в API - коварство иллюзорной простоты

Поделиться
HTML-код
  • Опубликовано: 10 дек 2024

Комментарии • 14

  • @МихаилБратухин
    @МихаилБратухин 7 месяцев назад +1

    В докладе вскользь упомянули, про то, что не нужно вызывать метод values у перечислений. Оказывается, там очень интересная магия скрыта под капотом. Есть описание в частности в статье на Хабре "Загадки Enum'ов". Но приведённое в данном ролике решение, как-то замерялось на производительность? А то про values в докладе упомянули и это хорошо, а вот насколько "тяжелее" могло или не могло стать данное решение для приложения? Также в комментариях ниже упоминали, про опасность складывать любое "неизвестное" значение в Map'у, т.к. может потенциально стать вектором атаки злоумышленника.

  • @СергейНауменко-з4о

    Крутой доклад! сейчас у нас такая же проблема попробую ее решить этим способом, спасибо!

  • @Alex-he1zh
    @Alex-he1zh 3 года назад +3

    Интересный подход, но его использование может привести к отказу всей цепочки микросервисов, работающий на «платформа», когда злоумышленник начнет посылать сообщения с уникальными строками вместо enum. Мапа будет разрастаться, и oom не заставит себя ждать. Можно на weak мапе сделать то же самое, но с защитой от oom.
    Однако, дедупликация делается только ради использования “==“ вместо “equals” при сравнении объектов (не enum констант), что кажется довольно сомнительной затеей.

  • @АнтонБаркалов-ш3ф
    @АнтонБаркалов-ш3ф 3 года назад +5

    Мы напилили "микросервисов", а теперь из-за Enum нам надо в них во все вносить изменения. Ну да, виноват Enum)

    • @ilyasazonov3901
      @ilyasazonov3901 3 года назад +1

      @@kirillsh8383 Именно ситуацию с unknown мы проговорили. Если микросервис как-то использует enum для логики, то unknown хорошо работает, потому что логика должна понимать, что пришло что-то неожиданное. Но нередко вот эти значения, пришедшие снаружи, нужно просто передать по цепочке в другой микросервис и тогда unknown приводит к потере данных.

    • @ilyasazonov3901
      @ilyasazonov3901 3 года назад +1

      Enum ни в чём не виноват, просто Enum плохо подходят для решний с микросервисным API. Так то конечно удобнее сделать монолит. Но мы как раз о том случает, когда микросервисы уже данность.

  • @armenarz4062
    @armenarz4062 Год назад +1

    в случаее изменении в либс. надо деплоить все микросервисы у которых есть зависимость от него, если у вас это 3-5 микросервисы - нормально, если 10-50 - > зовите нового Архитектора . Если у вас зависимость - значет у Вас бизнес контекст в нескольких сервисах - а вы хотите деплоить только один ....

  • @kolyuchkin
    @kolyuchkin 9 месяцев назад

    Интереснее получится, когда Enum передается не в составе какой-нибудь dto-хи сразу в query-param и вредный пользователь ввел несуществующее значение.

  • @n12ox
    @n12ox 3 года назад +2

    "Общая библиотека в микросервисах..." Красивое.

  • @barefooted
    @barefooted 3 года назад

    Будет ли spring boot starter?

  • @pavelpetrashov2975
    @pavelpetrashov2975 3 года назад +7

    Кто-то платил за это)

  • @bananasba
    @bananasba Год назад

    проблема явно не в енаме, а в том, что все зависят от некой платформы, причем сильно.

  • @alekseysidorenko1855
    @alekseysidorenko1855 3 года назад +1

    Руками править версию платформы? Так реально кто-то делает?

    • @ilyasazonov3901
      @ilyasazonov3901 3 года назад

      Я не удивлюсь, если так делает большинство небольших компаний. Или стартапов. Увы.