grammY у порівнянні з іншими фреймворками для створення ботів

Хоча grammY використовує певні концепції, які відомі завдяки іншим фреймворкам для ботів та вебзастосунків, він був написаний з нуля для забезпечення кращої організації коду і швидкості роботи.

Будь ласка, враховуйте, що це порівняння є упередженим, хоча ми й намагалися надати вам обʼєктивний огляд переваг та недоліків використання grammY у порівнянні з іншими бібліотеками. Ми намагаємося підтримувати цю статтю в актуальному стані. Якщо ви помітили, що інформація в цій статті застаріла, будь ласка, відредагуйте її, скориставшись посиланням внизу.

Порівняння з іншими фреймворками на JavaScript

Спочатку оберіть вашу мову програмування

Оскільки ви читаєте документацію до фреймворку з екосистеми JavaScript, вам, напевно, цікавіше порівняння з бібліотеками, які працюють на Node.js або Deno. Однак, якщо це не про вас, прокрутіть униз, щоб перейти до порівняння про те, які мови програмування підходять для розробки ботів найкраще. Також ви знайдете коротке порівняння з фреймворками з інших мов, переважно з Python.

Існує два головних проєкти, якими надихався grammY, а саме: Telegraf та NTBA. Наразі ми зосередимо наше порівняння на них, але в майбутньому ми (чи ви?) можемо додати інші порівняння.

Telegraf

grammY походить своїм корінням від Telegraf, тож нижче приведений короткий огляд того, як ці фреймворки повʼязані між собою.

Коли grammY був створений, Tekegraf був дивовижною бібліотекою, і без неї grammY не був би там, де він є зараз. Однак раніше Telegraf був написаний на JavaScript (у 3-й версії). Анотації типів додавалися вручну і погано підтримувалися, тому вони зазвичай були неповними, неправильними і неактуальними. Надійні анотації типів є важливим аспектом будь-якої серйозної бібліотеки, оскільки вони надають підтримку інструментів розробки, а також дозволяють вам значно швидше виконувати необхідні зміни у вашій кодовій базі. Чимало людей надають перевагу типізації при розробці складних ботів, а для декого відмова від неї є взагалі критичною.

У 4-й версії Telegraf намагався виправити це шляхом міграції всієї кодової бази на TypeScript. На жаль, багато з описаних типів були настільки складними, що їх було дуже важко зрозуміти, але вони були правильними. Більше того, міграція виявила безліч дивних речей (приклад) у кодовій базі, через які дуже важко зробити правильну типізацію для існуючого коду.

У результаті, незважаючи на те, що у 4-й версії було зроблено спробу покращити коректність типів і інструментів розробки, це призвело до того, що Telegraf став значно складнішим у використанні, ніж його нетипізований попередник. Цілком зрозуміло, що багато користувачів Telegraf 3 не бажали переходити на нову версію. Новим користувачам також стало важче починати роботу з новою версією.

grammY зробив крок назад і переосмислив фреймворк для ботів з типобезпекою, ставлячи зручність на перше місце. Це дозволило уникнути багатьох дратівливих дискусій про те, як впоратися з дивною внутрішньою типізацією. Це дало змогу проєкту мати чистий, узгоджений, компільований код, який надає користувачам відмінні типи (читай підтримка редакторів коду). Безпека типів, в свою чергу, дозволяє використовувати більш просунуті функції, які істотно змінюють наше уявлення про розробку ботів, такі як перетворювачі API.

Незважаючи на те, що Telegraf 3 все ще використовується багатьма активними ботами, бібліотека значно застаріла. Крім того, екосистема плагінів Telegraf перейшла до Telegraf 4 (принаймні ті, що не були перенесені до grammY).

У цьому порівнянні порівнюються лише grammY та Telegraf 4.

Ось список причин, чому варто використовувати grammY замість Telegraf:

• grammY завжди підтримує останню версію Bot API. Telegraf часто відстає на кілька версій.
• grammY має документацію. Telegraf не має її: замість неї слугує згенерований довідник API, який не містить пояснень, а ті кілька посібників, що існують, є неповними і їх важко знайти.
• grammY використовує TypeScript; типи просто працюють і будуть відповідати вашому коду. У Telegraf часто потрібно писати код певним чином, інакше він не скомпілюється — попри те, що насправді він працюватиме без проблем.
• grammY інтегрує підказки з офіційного довідника Bot API, які допомагають вам під час написання коду. Telegraf не надає вам жодних пояснень щодо вашого коду.
• Багато інших речей, як-от краща продуктивність, велика екосистема плагінів, документація, перекладена для мільярдів людей, краща інтеграція з базами даних і вебфреймворками, краща сумісність з середовищами виконання, розширення VS Code тощо, які ви відкриєте для себе в процесі роботи.

Ось список причин, чому варто використовувати Telegraf замість grammY:

• У вас вже є великий бот, написаний на Telegraf, і ви більше не працюєте над ним. У такому випадку міграція на grammY може зайняти більше часу, ніж ви заощадите в довгостроковій перспективі, незалежно від того, наскільки плавною буде міграція.
• Ви знаєте Telegraf, як свої п’ять пальців, і вам не потрібно змінювати свої навички. grammY представляє ряд нових концепцій, які можуть бути незнайомими, якщо ви використовували тільки Telegraf, а використання grammY означає, що ви будете відкривати для себе нові речі.
• Є кілька деталей, де Telegraf і grammY використовують різний синтаксис для досягнення однієї і тієї ж мети, і ви просто віддаєте перевагу одному стилю над іншим. Наприклад, Telegraf використовує bot.on(message("text")), а grammY використовує bot.on("message:text") для прослуховування текстових повідомлень.

NTBA

Пакет node-telegram-bot-api є другим великим проєктом, який вплинув на розробку grammY. Його головна перевага над іншими фреймворками полягає в тому, що він дуже простий. Його архітектуру можна описати одним реченням, тоді як grammY для цього потрібен посібник на сайті документації. Ми впевнені, що всі ці пояснення на сайті grammY полегшують людям початок роботи, але дуже спокусливо мати бібліотеку, яка взагалі не потребує жодних пояснень.

З іншого боку, це добре лише в короткостроковій перспективі. Ідея помістити все в гігантський файл і використовувати примітивний EventEmitter для обробки потоку складних обʼєктів, так званих вебзапитів, принесла багато болю в світ ботів Telegram і, безумовно, завадила реалізації багатьох гарних ідей.

Боти завжди починаються з малого, але надійна структура повинна забезпечити їм простий шлях для розширення та масштабування. На жаль, NTBA катастрофічно не справляється з цим завданням. Будь-яка кодова база з більш ніж 50 рядків, що використовує NTBA, перетворюється на жахливий безлад з перехресних звернень, які нагадують спагеті. Вам цього не хочеться.

Інші фреймворки

Наразі не існує інших бібліотек на TypeScript, які варто використовувати для створення ботів. Все, окрім grammY, Telegraf та NTBA, здебільшого не підтримується, а отже, жахливо застаріло.

Ви щойно створили нову чудову бібліотеку, а ми про неї ще не знаємо? Ви можете змінювати цю сторінку і додавати порівняння або поділитися з нами своїми думками в груповому чаті!

Порівняння з фреймворками з інших мов програмування

Існують причини надавати перевагу іншій мові програмування замість TypeScript. Найважливіше, щоб вам подобалося працювати з вашими інструментами та мовами. Якщо ви твердо налаштовані використовувати іншу мову програмування, то можете припинити читання тут.

Оскільки ви продовжуєте читати, напевно, вам цікаво, чому grammY написаний мовою TypeScript і чому вам теж варто розглянути можливість вибору цієї мови для вашого бота.

У цьому розділі ми розглянемо, якими є переваги TypeScript порівняно з іншими мовами, коли мова йде про розробку Telegram ботів. Це порівняння буде обмежене Python, Go та Rust. Не соромтеся додавати більше розділів, якщо ви хочете порівняти TypeScript з іншими мовами.

Деякі з наступних пунктів частково ґрунтуються на особистих думках. У людей різні вподобання, тому сприймайте цей розділ з певною долею скепсису.

Фреймворки, написані на Python

Порівнюючи TypeScript та Python, можна навести чіткий приклад. Обирайте TypeScript і ви отримаєте задоволення:

1. Кращий інструментарій редактора. Анотації типів grammY є надзвичайними. Хоча у версії 3.5 Python запровадив типізацію, вона не використовується в екосистемі так широко, як у випадку з JavaScript/TypeScript. Тому це не може зрівнятися з тим, що ви отримуєте “з коробки” з grammY та її супутніми бібліотеками. Разом з типами зʼявляється автодоповнення на кожному кроці розробки, а також корисні допоміжні підказки з поясненнями та посиланнями.

2. Легше масштабувати кодову базу. Система типів має ще одну перевагу — вона дозволяє масштабувати кодову базу вашого бота. Набагато складніше це робити в проєктах, написаних мовою з гіршою типобезпекою.

3. Легше масштабувати навантаження. Якщо ваш бот починає набувати популярності, то масштабувати ботів, написаних на JS, а не на Python, значно легше.

4. Вища швидкість реакції вашого бота. Наразі V8 та його конкуренти роблять JavaScript найшвидшою скриптовою мовою у світі. Якщо ви хочете, щоб ваш бот був максимально швидким, але при цьому насолоджуватися динамічною мовою, то grammY — ваш найкращий вибір.

Як завжди, мови програмування чудово справляються з певними завданнями, а для інших їх слід уникати. Це не виняток.

Наприклад, за нинішнього стану екосистем, все, що пов’язано з машинним навчанням, не варто робити на JavaScript. Однак, коли мова йде про вебсервери, TypeScript, як правило, є набагато кращим вибором.

Фреймворки, написані на Go

Якщо ви володієте і TypeScript, і Go, то розумною мірою для вибору мови для вашого бота є баланс між швидкістю розробки та швидкістю виконання.

Обирайте grammY, якщо ви не зовсім впевнені в тому, що створюєте. TypeScript дозволяє ітераційно змінювати кодову базу з неймовірною швидкістю. Він чудово підходить для швидкого створення прототипів, випробовування нових речей, знайомства з ботами та швидкого виконання завдань. Як правило, за допомогою TypeScript можна легко обробляти ~100 000 000 оновлень на день, але якщо вийти за рамки цього показника, то знадобиться додаткова робота, наприклад, використання ще одного плагіна grammY.

Вибирайте бібліотеку, написану на Go, якщо ви вже досить добре знаєте, що будете створювати (ви не очікуєте, що вам знадобиться велика допомога), і ви вже знаєте, що ваш бот буде обробляти дуже велику кількість оновлень. Як мова, що компілюється нативно, Go перевершує TypeScript за швидкістю роботи процесора на кілька порядків. Це набагато менш актуально, коли ви пишете бота, тому що більша частина часу витрачається на очікування мережі, але з часом почне мати значення, як швидко ваш бот може розбирати JSON. У таких випадках Go може бути кращим вибором.

Фреймворки, написані на Rust

Можна зробити схоже зауваження, як і у випадку з Go, але у випадку з Rust воно ще сильніше. У певному сенсі, вам знадобиться навіть більше часу на написання Rust, але ваш бот буде ще швидшим.

Також, будь ласка, зверніть увагу, що використання Rust є цікавим, але рідко необхідним для ботів. Якщо ви хочете використовувати Rust, то робіть це, але слід враховувати, що це скоріше через вашу любов до Rust, ніж через те, що він є правильним інструментом для цієї роботи.

Як не погодитися з цим порівнянням

Якщо ви вважаєте, що на цій сторінці щось не так, не варто засмучуватися! Будь ласка, повідомте нам про це в груповому чаті! Ми будемо раді, якщо ви поділитеся з нами своєю точкою зору. Звичайно, ви також можете просто відредагувати цю сторінку на GitHub або створити issue, щоб повідомити про помилки чи запропонувати щось. Ця сторінка завжди може бути більш обʼєктивною та справедливою.