Комментарии 14
Есть как минимум две замечательные библиотеки для ТГ под .нет:
Telegram.Bot - собственно, для ботов
WTelegramClient - для написания альтернативного клиента ТГ. Бывает нужно, если не устраивают ограничения бота (мне например, нужно было пересылать файлы > 20МБ)
Спасибо за WTelegramClient. Telegram.Bot в статье я уже упомянул. Проблема в том, что обе эти библиотеки для работы с ботами через API требуют написания дополнительного кода для обработки сообщений. Хотелось бы сосредоточиться сразу на обработке команд, а не на этих деталях. Об этой проблеме в .NET я и упомянул в статье.
Для пересылки файлов больше 20мб подключается локальный API.
https://github.com/tdlib/telegram-bot-api
Зачем столько бойлерплейт кода, если тг поддерживает веб хуки и простейший бот это приложие в 3 строчки плюс модель с вызовом http post в ответ, завернутый в aws/azure лямду
Я вот тоже не понимаю зачем все эти библиотеки непонятные, на том же PHP с нуля всё написать можно без всяких библиотек и запустить это всё почти на любом самом дешёвом хостинге
Я вот тоже не понимаю зачем все эти библиотеки непонятные
Затем, что C# - строго-типизированный язык, ему нужны типы данных, и эти непонятные библиотеки уже всё для вас имплементируют, например, Chat или Message. Вы точно хотите это писать руками?
запустить это всё почти на любом самом дешёвом хостинге
Так и на шарпе можно.
Я в самом начале статьи сказал: "Из-за особенностей проекта пришлось выбрать long-polling модель вместо webhooks"
Вы сравниваете тёплое (вебхуки vs long-polling) с мягким (количество кода).
Почему не вебхуки? Для них нужно светить задницей HTTP-сервером в интернет, либо завязываться на облако. А зачем мне этот ваш амазон, если с long-polling можно запустить бота хоть на тостере?
Статья называется "Просто, но быстро". Просто и быстро это в три строчки сделать хэндлер веб хуков и залить лямбду в aws на free tier(1 миллион запросов в месяц бесплатно). И желательно на том, что имеет короткое время старта, по-этому и "c# почему-то не самый оптимальный выбор для написания телеграм ботов. " А прикручивание лонг-пуллинга, медиатора и прочее для такой задачи выглядит как overkill. Если уж тут делать "энтерпрайзно", то бот должен быть простым фасадом перед апи бэкэнда, а не крутить логику самостоятельно и по-этому 90% того, что написано в статье, особенно включая трюки с скопом, просто не нужно.
По-моему это не единственная проблема Шарпа, поражающая отсутствие либ для создания телеграм ботов, и кучи чего ещё.
На сколько я помню, ещё года 3 назад нужно было очень сильно пострадать, чтобы запустить .net приложение на сервере (если конечно сервер не на окнах, тогда страдать придется с процентами). А зачем страдать, когда можно взять любой кроссплатформенный язык и развернуть бота за пару-тройку минут.
Поэтому в принципе любая работа с сетью, которая должна выполняться дольше часа, на шарпе довольно затруднительна, ибо в этом направлении он развиваться не мог.
, поражающая отсутствие либ для создания телеграм ботов
Автор буквально в статье перечисляет либы для создания ботов, что значит "отсуствие"?
На сколько я помню, ещё года 3 назад нужно было очень сильно пострадать
Нет, это не правда, проблемы были до 2016(8 лет назад), потом вышел dotnet core, сейчас в принципе весь дотнет ориентирован на линукс и работу в контейнерах.
Поэтому в принципе любая работа с сетью, которая должна выполняться дольше часа, на шарпе довольно затруднительна
В чем она конкретно она затруднительна, если оно работает через через sys/socket как и остальные?
этом направлении он развиваться не мог.
что значит "не мог развивать" если он сейчас по перфомансу обходит тоже самый Go? Это он так "не развился", получается в будущем можно топ-1 ждать, быстрее раста и с++?
У нас сервис на шарпе работает последние пол года без ребутов, держит веб-сокет коннекты от 12 часов до недели, которые разрываются только по инициативе клиента. Соединения по grpc вообще практически бесконечные. Работает в кубере (linux). Держит адовые нагрузки, отлично масштабируется, телеметрия просто божественная, я лучше не видал вообще нигде и ни у кого.
C# это и есть кросс-платформенный язык, работает на всех платформах включая ARM. Вы видимо в спячке провели последние лет 5. Сегодня dotnet это наимощнейшая платформа, с которой сложно в принципе конкурировать и мало кто это может делать в полной мере.
простым фасадом перед апи бэкэнда
Ничего не мешает поменять логику вызовов команд, которые меняют что‑то в базе, на вызов апи бэкэнда.
хэндлер веб хуков и залить лямбду в aws на free tier(1 миллион запросов в месяц бесплатно)
Да, так конечно быстрее. Но опять, не всегда получается делать через хуки и остается вопрос хранения состояния шагов и команд пользователя.
особенно включая трюки с скопом, просто не нужно.
Опять же. А как тогда хранить состояние шагов пользователя?
А прикручивание лонг-пуллинга, медиатора и прочее для такой задачи выглядит как overkill
Разве для каждой команды выделен собственный обработчик — уже overkill? Так же было бы с хэндлером веб хуков, пришлось бы разделять каждый обработчик в свой класс, из-за чего привело бы опять к медиатору.
И хотя собственная реализация медиатора может показаться излишней. Но давно требовалась возможность в Mediatr оборачивать публикации уведомлений в PipelineBehavior и уведомлять конкретных подписчиков. В результате просто добавили доступ к уведомлениям при их публикации при публикации Mediatr.
Начав искать готовые решения, столкнулся с небольшим разочарованием:
оказалось, что подходящих фреймворков нет, и придется разрабатывать бота
с нуля.
aiogram для вас шутка? Или вы в Bing искали ? Одна из самых популярных и мощных библиотек для telegram ботов
Просто, но быстро. Телеграм бот на коленке