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