Комментарии 7
Позанудствую: Long polling (а не pooling).
Спасибо, исправляю... Походу у меня в голове наложилось pull на pool. А дальше всё просто: пушить - толкать, пулать - тянуть. Кстати, почему polling - непонятно, ведь poll - это "голосовать" :(
Слово poll достаточно многозначное. Если верить словарной статье в Multitran, среди значений глагола (to) poll есть и такие:
Если что, telegraf и в es модули умеет, и в typescript))
GrammY тоже.
Я начал плотно погружаться в NodeJS в 2019-м году и сразу с import'ов. До этого я использовал JS только на фронте и там был RequireJS и require. Мне кажется, что документацию с import'ами пишут разработчики, которые более ориентируются на современные тенденции развития языка, чем те, кто использует в документации require.
О, годнота на хабре. Только Tequila Framework кажется лютым оверинжинирингом для такой задачи. Ну и Typescript как-то уже везде.
Спасибо :)
Ну, не такой уж и лютый. Во-первых, это мой собственный код - я его знаю вдоль и поперёк. Гордиться там особо нечем - я его писал 5 лет назад, когда только начинал в nodejs по-взрослому, но он работает. Во-вторых, grammY не имеет собственной обвязки для node'овских http-серверов, её приходится делать, если хочешь запускаться и в режиме webhook (а не только в long polling). То же самое относится и к запуску в режиме командной строки с параметрами - нужен какой-то парсер аргументов (commander, в моём случае). И к конфигурации - нужно считывать локальную конфигурацию с токеном подлкючения к Telegram API.
Но в целом согласен - легкий оверинжениринг присутствует. Можно откинуть commander, упростить локальную конфигурацию (считывать порт, домен, пути к сертификату и ключам, токен из настроек окружения или того же файла ./cfg/local.json), самостоятельно обернуть http & https модули для поднятия веб-сервера (http - за прокси и https - как standalone). Суть модульного монолита - в переиспользовании модулей "монолита" в других "монолитах". @teqfw/di & @teqfw/core как раз и занимаются связыванием/развязыванием кода по модулям. Например, у меня есть ещё модуль @teqfw/db - занимается обработкой соединений с реляционными БД (обёртка на knexjs). В некоторых ботах он может использоваться, в некоторых нет. Модули подключения к различным API третьих сторон тоже могут использоваться спорадически.
В целом, количество оверинжинирига зависит от того, как дальше будет применяться общий пакет (@flancer32/teq-telegram-bot). Если для ботов, где все команды имплементируются в бот-приложениях - то да, можно сделать и попроще. Если же для ботов, которые будут шарить модули (npm-пакеты) между собой - то вот уже и не оверинжениринг вовсе :)
По поводу TypeScript - у меня это религиозное (написано 3 года назад, но пока что отношение не изменилось). Я пару лет писал на GWT (Java-to-JS) и считаю, что излишне заявлять о родственности (TS как суперсет от JS), раз уж всё равно нужна транспиляция. Так-то и C# можно в JS транспилировать, и Python, и brainfuck. Любая "накладка", "обёртка" на JS (тот же TS) добавляет что-то своё, но в то же самое время что-то и отнимает (экранирует). А по итогу всё равно всё сводит к JS после транспиляции. Вот и получается, что я усекаю свои возможности по использованию JS, применяя транспилируемые языки. Код после транспиляции не похож на оригинальный даже для суперсета - TypeScript'а. Я использую связывание кода через JSDoc'и. Мне этого достаточно. Зато у меня в работе тот же код, что и в разработке - очень помогает при отладке.
Мой опыт создания телеграм-бота на NodeJS/grammY