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