Comments 6
О! Вот это прям спасибо. Сам делаю ботов на джаве по поводу и без и да, действительно надоело постоянно одно и то же делать! В следующий раз постараюсь вспомнить о вашем проекте
Спасибо за комментарий! На самом деле я видел эту реализацию и у нее есть свои достоинства, конечно. Однако, я во многом не согласен с подходами, которые реализованы там. В своем проекте я придерживаюсь модульности и гибкости, в частности стояла задача сделать фреймворк максимально тонким и не приносить пользователю того, чего ему не нужно.
Если говорить про аннотации и подобие Spring Web, то на мой взгляд подход MVC в том виде, в котором он представлен в Spring Web не очень ложится на разработку Telegram-ботов. Поэтому в первых версиях фреймворка я решил отказаться от аннотаций, но задача на проработку в бэклоге есть и их поддержка обязательно появится в каком-то виде в будущем.
С одной стороны стертер наверное полезный. Сам я пользуюсь 'org.telegram:telegrambots-springboot-longpolling-starter' от самого телеграма. Там по сути прям большого функционала не надо. Отправить сообщение-принять сообщение. Обвзяки в виде обработки событий делал вручную, там тоже все легко. Но в следующий раз попробую ваш стартер
Проблема мне видится ровно одна: как вы и сами ее озвучили в начале статьи - заброшенные библиотеки. Вы сейчас написали стартер, ты с ним работаешь, в свои проекты внедряешь. Потом, хоба, и телеграм меняет свой АПИ. А вы забросили свой стартер. И тебе надо опять бегать по гитхабу и искать свежую версию кого-то другого. Нашел, а там интерфейсы и классы совершенно другие. Надо значит рефакторить код. Тогда легче взять лонгполлер от самого телеграма. Они обновили АПИ, ты обновляешь версию в грейдле/мавене и с большой вероятностью даже код править не придется.
Благодарю за комментарий!
Сам я пользуюсь 'org.telegram:telegrambots-springboot-longpolling-starter' от самого телеграма
К сожалению, я так и не смог найти никакого подтверждения, что эта библиотека именно от самих разработчиков Telegram - на GitHub у нее есть конкретный разработчик, который развивает проект.
Потом, хоба, и телеграм меняет свой АПИ. А вы забросили свой стартер. И тебе надо опять бегать по гитхабу и искать свежую версию кого-то другого.
При проектировании своего решения, как я уже писал в статье, упор был в гибкость и независимость от внешних решений. Что касается смены АПИ, то на мой фреймворк это никак не повлияет, так как в рамках него я использую готовую реализацию API от pengrad - этот проект уже много лет развивается и заслужил доверие многих пользователей.
Соответственно при критических изменениях достаточно будет лишь поднять версию непосредственно API от pengrad, но при желании можно даже заменить реализацию на другую, все необходимые абстракции для этого уже представлены.
Они обновили АПИ, ты обновляешь версию в грейдле/мавене и с большой вероятностью даже код править не придется.
Если у API критически поменяются контракты (что-то удалится, добавится), то конечные Handler-ы в любом случае придется рефакторить. Со своей стороны я стараюсь не привносить Breaking Changes в проект, однако нужно понимать, что даже самим разработчикам Spring порой не удается обойтись без этого.
Мой проект открыт для всех желающих в него что-то добавить или изменить - поэтому вы всегда можете прийти, оставить ишью или даже доработать проект.
Больше никаких велосипедов: готовый Spring Boot Starter для Telegram-ботов