Штош, я только начал и не собираюсь сдаваться!!!!!!!!!!
Рубрика «в предыдущих сериях»:
Для связи telegram бота и функционала, который вы хотите ему придать, необходимо реализовать соответствующий функционал с использованием языка программирования. Как я уже писал в первой части, для реализации бота был выбран фреймворк nestJS (язык программирования typescript) и кроме базовых файлов, которые автоматом устанавливаются при установке проекта, нам понадобится всего лишь два дополнительных файла.
Практически базовая структура nestJS проекта
Для бота написанными лично мною являются файлы bot.module.ts и bot.update.ts. Наполнение bot.update.ts следующее.
Ссылка на приложение, текст и кнопка запуска
Наполнение bot.module.ts следующее.
По сути просто связующий файл для импортов
В самом telegram боте после его «активации» вы увидите следующее.
В самом же списке контактов вы увидите следующее.
Ну вот и все, дорогие мои, все этапы создания мини-приложения для telegram пройдены, можете все это повторить, но уже для других сервисов, например, игр тайм-киллеров.
А теперь «микросерверность» и все, что с этим связано, nikita17cm все это для тебя, мой единственный комментатор!!!!!
Для начала рассмотрим, а что же является альтернативой микросервисной архитектуры и какие минусы у такого подхода, который был назван монолитной архитектурой. Представим, что на бэкенде у меня один проект и взаимодействие с ботом является составной частью основного бэкенда. На этом этапе никаких проблем нет, как вы все видели, код взаимодействия с ботом минимален и не сложен. Время проходит и я, например, решаю реализовать функционал оплаты, через робокассу или юмани. Реализация оплаты уже посложнее, код объемнее и отлаживать или тестировать его функционал становится сложнее, но все еще терпимо в рамках единой кодовой базы проекта. А потом мы добавляем логирование (для отслеживания ошибок), кеширование (для ускорения работы приложения), брокер сообщений (для гарантированной доставки важных сообщений) и т.д. Все это приводит к тому, что теперь процедуру отладки или тестирования функционала становится очень сложно проводить, так как изменения в одной части кода могут повлиять на другую часть кода. А что если как-то выделить код, который отвечает за какой-то один функционал (бот, логирование, кеширование и т.д.) и, самое главное, изолировать этот функционал между собой? В этом и есть основной смысл микросервисной архитектуры, который позволяет абсолютно независимо разрабатывать, тестировать и отлаживать взаимодействие отдельных микросервисов между собой. Накатили новые изменения и сломался функционал логирования (кеширования, брокера сообщений)? Не проблема, основной функционал вашего приложения работает, как раньше, просто откатываете изменения и исправляете ошибку. Именно поэтому функционал бота у меня выделен в отдельное приложения, я сразу стал так писать, а не писал сначала все в одном проекте, а потом решил часть проекта выделить в отдельный микросервис. Надеюсь, стало немного понятно, а вообще на ютубе полно видео на эту тему, которые достаточно доходчиво объясняют все интересующие вас аспекты.
А, ну и конечно, как я уже ранее писал, мини-приложение уже готово и ждет своих пользователей, как говорится welcome t.me/Socionyx_Bot/socionyx.
Кроме того, завел telegram канал t.me/socionyxchannel, где буду писать о дальнейших этапах разработки и продвижения, разработанных мною приложений.
Буду премного благодарен за обратную связь и замечания по работе текущего мини-приложения.
