Pull to refresh
6
0
Дмитрий @Kataanee

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

Send message

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

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

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


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

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

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

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

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

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

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

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

Information

Rating
Does not participate
Location
Россия
Registered
Activity

Specialization

Backend Developer, Fullstack Developer
C#
.NET Core
Vue.js
JavaScript