Всем привет!

Сегодня расскажу про такую штуку, как rate limiters.
Как следует из названия это компонент для ограничения числа запросов в интервал времени.
Может возникнуть вопрос - причем здесь Java? Да, обычно такие штуки разворачивают на инфраструктуре - например, в k8s или nginx.
Если так можно сделать - так и нужно делать)
Когда так сделать не получится:
1) алгоритм ограничения числа запросов нестандартный, поэтому нужна Java, чтобы его запрограммировать)
2) нужна возможность продвинутого мониторинга числа пропущенных и отбитых запросов
3) при изменении параметров rate limiting нужна умная ребалансировка. Т.е. нельзя просто сбросить счетчики в ноль, т.к. это приведет к падению сервиса, который защищает rate limiter.
4) ну и наконец нет подходящей инфраструктуры

Второй вопрос - в каких кейсах это может понадобиться:
1) не уронить стоящий за вами сервис
2) приоритизировать какие-то запросы вашего API по сравнению с другими чтобы не упасть самому
3) ограничить число запросов по тарифному плану клиента

Вот неплохая статья про существующие алгоритмы rate limiting https://habr.com/ru/post/448438
Неплохая библиотека для Java - Bucket4J https://github.com/bucket4j/bucket4j
Развивается порядка 8 лет, к слову разработчики из России.
Вот хорошее видео от разработчиков с примерам настройки - https://www.youtube.com/watch?v=OSNFNxgZZ3A
В простых случаях можно использовать Resilience4j, удобно со Spring Boot посредством аннотаций https://www.baeldung.com/spring-boot-resilience4j Resilience4j библиотека более широкого профиля, отвечает за отказоустойчивость, см. детали в статье

#java #libraries #highload #interview_question #rate_limiters

Всем привет!

Возвращаясь к теме Machine Learning. Если погуглить эту тему, то в первых сторонах будет Python и библиотеки на Python. Почему не Java - вот тут попытка дать ответ: https://habr.com/ru/companies/piter/articles/429596/ Согласен с тем, что для такой большой экосистемы как Java возможностей для ML должно быть больше. Микросервисы конечно рулят, мультиплатформенность, все такое, но Java разработчиков много и по ML задач будет также очень много.

Как ложку меда хочу отметить, что какие-то ML библиотеки для Java все же есть https://onix-systems.com/blog/top-10-java-machine-learning-tools-and-libraries. И NLP до кучи https://www.baeldung.com/java-nlp-libraries NLP на всякий случай - это natural language processing)))

#ml #nlp #libraries

Всем привет в новом году!

Предположу - многие знают о том, что для Data Science, ML, DL, AI в основном используют Python. Я уже подымал эту тему тут https://t.me/javaKotlinDevOps/142
Хотел бы подчеркнуть важность экосистемы - в Python было создано так много ML\DL\NLP библиотек, что догнать его другим экосистемам стало очень сложно.
А тут недавно и ChatGPT появился, что привело к взрывному росту популярности ML и AI ... Ну так вот - уже летом этого года началась разработка 2 альтернатив для работы с GPT моделями в Java.

1) langchain4j https://github.com/langchain4j/langchain4j Характерно, что проект сделан на основе одноименной Python библиотеки. Поддерживается в Quarkus.
2) конечно же Spring в виде Spring AI - https://docs.spring.io/spring-ai/reference

Оба проекта находятся в начальной стадии своего развития, версии вида 0.х, обновления выходят часто.

Еще важный момент - оба проекта имеют коннекторы к популярным GPT провайдерам - OpenAI (ChatGPT), Azure OpenAI...

Вот тут описан элементарный пример работы со Spring AI - https://habr.com/ru/articles/784128

А вот тут можно почитать про основные понятия и примеры кода для полноценной работы с ML моделями:
https://www.javaadvent.com/2023/12/java-and-the-ai-frontier-leveraging-modern-tools-and-techniques-for-machine-learning.html


#ai #java #ml #libraries

Всем привет!

Я уже не раз говорил и повторю еще раз - мир Java хорош своей огромной базой opensource библиотек на все случаи жизни.
Даже для работы с LLM (ChatGPT) уже библиотеки появляются https://t.me/javaKotlinDevOps/241
И для прочего Machine Learning тоже https://t.me/javaKotlinDevOps/142

А еще на Java можно писать Telegram боты https://www.baeldung.com/spring-boot-telegram-bot

#java #libraries

Всем привет!

Продолжаю читать книгу "Эффективная работа с унаследованным кодом". Наткнулся на интересную мысль, на первый взгляд подтверждающую тезис: разработка - искусство компромиссов.

Мы все используем библиотеки. Когда нужно написать тест (а книга в основном про то, как упростить написание тестов для legacy) - часто в наш класс передаются библиотечные объекты. И тут могут быть две проблемы:
1) объект-синглтон
2) final объект или объект с методами, которые не возможно переопределить.
Эти две проблемы приводят к одному и тому же - мы не можем создать mock, приходится инициализировать для тестов реальный объект из библиотеки. А он может быть "тяжелым", превращающий модульный тест в интеграционный.

Как вариант решения этой проблемы предлагается:
1) для singleton создавать фасад, который разрешает замену объекта через setter, т.е. по сути нарушать суть паттерна singleton
2) для final методов и объектов - убрать final, объявляя их логическими final в документации.

Оба предложения по сути об одном - нарушаем принципы проектирования на уровне языка, зато делаем возможным тестирование кода.

В целом - "соль" в этом есть. Код без тестов опаснее кода, нарушающего принципы проектирования. Но я бы уточнил, что оба метода - это крайние меры. А по хорошему, если вы разрабатываете код, который кто-то когда-то будет тестировать - надо заранее озаботится о тестируемости, и именно:
1) не создавать singleton самому, использовать для этого IoC контейнер. Spring если библиотека внутренняя, и у вас используется Spring, или CDI аннотации в других случаях. Причем это актуально не только для разработчиков библиотек, а для всех.
2) создавать интерфейсы для классов, вынесенных в клиентское API. Есть интерфейс - всегда можно создать mock в тесте без всяких ухищрений. Я против создания интерфейсов всегда и везде https://t.me/javaKotlinDevOps/235, но Java API - это как раз подходящий случай. Одних интерфейсов конечно же мало, нужно еще и четкое разделение на модель и сервисы. Первые можно использоваться AS IS в тестах, вторые часто приходится мокать. Да, спроектировать все правильно не так-то легко, но как говорится - дорогу осилит идущий.

#book_review #ood #dev_compromises #libraries