Обновить
6
0
Дмитрий@Kataanee

Тот самый джун с горящими глазами

Отправить сообщение

простым фасадом перед апи бэкэнда

Ничего не мешает поменять логику вызовов команд, которые меняют что‑то в базе, на вызов апи бэкэнда.

хэндлер веб хуков и залить лямбду в aws на free tier(1 миллион запросов в месяц бесплатно)


Да, так конечно быстрее. Но опять, не всегда получается делать через хуки и остается вопрос хранения состояния шагов и команд пользователя.

особенно включая трюки с скопом, просто не нужно.

Опять же. А как тогда хранить состояние шагов пользователя?

А прикручивание лонг-пуллинга, медиатора и прочее для такой задачи выглядит как overkill

Разве для каждой команды выделен собственный обработчик — уже overkill? Так же было бы с хэндлером веб хуков, пришлось бы разделять каждый обработчик в свой класс, из-за чего привело бы опять к медиатору.
И хотя собственная реализация медиатора может показаться излишней. Но давно требовалась возможность в Mediatr оборачивать публикации уведомлений в PipelineBehavior и уведомлять конкретных подписчиков. В результате просто добавили доступ к уведомлениям при их публикации при публикации Mediatr.

Я в самом начале статьи сказал: "Из-за особенностей проекта пришлось выбрать long-polling модель вместо webhooks"

Спасибо за WTelegramClient. Telegram.Bot в статье я уже упомянул. Проблема в том, что обе эти библиотеки для работы с ботами через API требуют написания дополнительного кода для обработки сообщений. Хотелось бы сосредоточиться сразу на обработке команд, а не на этих деталях. Об этой проблеме в .NET я и упомянул в статье.

Спасибо. Рад стараться, на этом моя эпопея еще не заканчивается. Постараюсь в ближайшее закончить еще один проект и написать о нем.

Информация

В рейтинге
Не участвует
Откуда
Россия
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Фулстек разработчик
C#
.NET Core
Vue.js
JavaScript