что такое threads в дискорде
Discord как корпоративный мессенджер и не только
Хочу рассказать про использование мессенджера Discord как основного средства коммуникации в команде. Опыт может быть полезен другим командам, использующим бесплатные мессенджеры, а также всем, кто ищет пути повышения эффективности использования мессенджеров.
Discord – программа странная и выдающаяся одновременно. Почему? Хотя бы потому, что про способы работы в Discord получилась целая статья.
Что-то пошло не так
В данной статье я рассматриваю исключительно мессенджеры, у которых основной функционал доступен бесплатно. Да, существуют прекрасные платные программы, но они за рамками данной статьи, даже если имеют бесплатный урезанный режим.
Обычные мессенджеры устроены так, чтобы работать «из коробки» и без всякого администрирования. Это вполне здравый подход, обеспечивающий низкий порог вхождения: просто создали групповой чат и общаемся в нём. По-другому эти мессенджеры не могут, так как сложные процедуры настройки отпугнут основную аудиторию. Но, как обычно, низкие начальные вложения оборачиваются высокими эксплуатационными издержками. Какие проблемы имеем в итоге.
Разделение по темам. Чем больше пользователей в группе, тем больше количество обсуждаемых тем. Большинство тем интересны ограниченному числу пользователей группы. Подход здорового человека заключается в том, чтобы создавать тематические группы и включать в них только тех, кому тема интересна – такая изоляция уменьшает «информационный шум» от ненужного контента. Но на практике это приводит к полному хаосу. Например, имеем 10 чатов по работе, 4 чата детского сада, 3 чата многоквартирного дома и так далее. И всё это в одном пространстве имён, поэтому мы начинаем путаться в чатах. Они уползают вниз списка, забываются, потом создаются дубликаты забытых чатов, но туда забывают добавить всех пользователей. Если же количество участников примерно от полсотни и выше, то никакие параллельные чаты уже не создаются – слишком сложно поддерживать актуальный список участников. Ведется один супер-чат, содержащий все вопросы жизни, вселенной и всего такого. Результат: большие группы в мессенджерах становятся «токсичными»: контент неинтересен из-за большого количества мусора, мы присутствуем в группах только из-за необходимости.
Избыточные нотификации. Каждому знакома ситуация, когда нам приходит слишком большое количество нотификаций различных мессенджеров. Рассмотрим пример. Пусть, у нас команда из 50 человек и каждый пишет в общий чат 5 сообщений в день. Тогда каждый получит по 50*5=250 нотификаций. Если считать, что для просмотра сообщения мы отвлекаемся на 30 секунд, то 250 нотификаций съедают 250*30=7500 секунд, что составляет 2 часа! А всю команду нотификации отвлекают на время 7500*50=375000 секунд или 104 часа! Вдумайтесь: 104 человеко-часа в день или 13 человеко-дней каждый день! Это 26% ресурсов команды. Такие большие числа получаем потому, что количество людей (50 человек) в чате входит в итоговую формулу квадратично (каждый нотифицирует каждого):
В реальности все несколько лучше, так как сообщения обычно появляются и читаются пачками. Но суть проблемы понятна: квадратичный рост потерь времени команды на нотификации. Кэп подсказывает два способа решения, но оба плохие:
Discord: начало
Теперь переходим к Discord. Прежде всего заметим, что в Discord есть два режима или, скорее, «вида»: назовем их «обычный» и «сервер». Они существуют параллельно и имеют разные цели. В «обычном» виде Discord – это такой же обычный мессенджер, как и все остальные. Даже с более ограниченными возможностями, чем тот же Skype:
Сервер
Чтобы работать с сервером, надо этот самый сервер иметь. Для определенности будем считать, что мы сотрудники стартапа «Рога и Копыта», поэтому наш сервер будет называться «РК». Создаем сервер путем нажатия на кнопку с большим знаком «+». Сервер – это уютное место, где будет проходить всё наше корпоративное общение (кроме 1-на-1, которое в «обычном» виде, вне сервера). Пользователи должны присоединиться к серверу по приглашению.
В левой панели сразу видим две новые сущности:
Теперь переходим к инструментам Discord, которые делают его эффективным для командной работы. Прежде всего это роли. Смысл в том, что мы настраиваем права доступа не для конкретных пользователей, а для ролей и даём эти роли людям. Список разных прав, которые может иметь роль, внушает: целых 32 пункта. Кроме того, у каналов мы настраиваем, какие права имеет роль в канале: чтение, написание, удаление сообщений и т.п.
Какие роли создавать – решаем сами. Роль соответствует некоему типичному набору действий пользователя. Например, на нашем сервере сделаем такие роли:
Каналы
Текстовые каналы на нашем сервере могут быть, например, такие:
Упоминания
Упоминания – ещё одна вещь, которая делает работу в Discord эффективной. Это когда мы пишем сообщение в текстовый канал, упоминая аккаунт с помощью специального синтаксиса:
Можно упомянуть роль:
А вот так можно упомянуть всех, кто есть в канале (любой из этих вариантов работает):
Тут вы можете сказать: «Ха! В Skype тоже можно упомянуть через @имя. И зачем упоминать всех, какой в этом смысл? Ведь сообщение и без того обращено ко всем».
Действительно, в Skype можно написать Vasya.Pupkin. Но в Skype вся польза от упоминания в том, что во всплывающем уведомлении будет добавлено, что «вас упомянули». Наверное, в этом есть смысл, но в Discord сделали лучше. Прежде всего заметим, что в Discord есть два вида нотификаций о новых сообщениях:
Поток сообщений в текстовых каналах не требует внимания, пока пользователь не упомянут.
Легко видеть, что такой подход решает описанную выше проблему избыточных нотификаций, если немного обучить пользователей правильному стилю работы. Например, такому:
И таких упоминаний в реальности очень мало, не более 2% сообщений. Обычно упоминают here когда задают вопрос не зная, кто конкретно может на него ответить. Все отвлекаются от работы и читают вопрос. Дальше люди, которым есть что сказать, остаются вести дискуссию, остальные возвращаются к своим делам. И не бойтесь, что here будет слишком много: лишний раз писать here в сообщении просто лень!
Также упоминаний не будет слишком мало. Хотя бы потому, что человек сам заинтересован позвать правильных людей упоминанием в своем посте, чтобы достичь нужного ему результата. Короче, всё это самобалансируется и получается норм. Что с остальными 98% сообщений? Их тоже надо читать, но не срочно. В удобное время с чашкой кофе прочитываем весь поток сообщений. Такое отложенное прочитывание не приводит к огромным потерям времени, как описано в начале статьи. Ведь читаем подряд, не переключая свой мозг между сообщениям и другими делами. И, что самое главное, сообщения не отрывают нас от работы.
Итого: проблема избыточных нотификаций полностью решена, и при этом обеспечено быстрое реагирование на важные сообщения.
А минусы какие?
Технические ограничения в Discord.
Стандартные возможности
В этой статье рассмотрены принципиальные отличия Discord от других мессенджеров, позволяющие значительно увеличить эффективность работы. А вот список мелких фич, которые типичны для мессенджеров и не являются чем-то выдающимся:
А еще есть.
Боты и возможность написания своих ботов. Но это уже совсем другая тема.
Итого
Discord – это в некотором роде мессенджер 2.0, имеющий средства для эффективного общения больших групп пользователей, в том числе и в корпоративном применении. Создатели программы не побоялись выйти за рамки парадигмы обычных мессенджеров – и получилось неплохо. И в то же время Discord не конкурент обычным мессенджерам, у него своя экологическая ниша. Ведь у простых пользователей, не айтишников и не геймеров, наступает шок и трепет от необходимости администрирования и непохожести на привычные программы.
Надеюсь, информации в статье достаточно, чтобы решить, надо вам это или нет.
UPD1: Комментарий JustDont:
Перед тем как советовать дискорд для контор, нужно обязательно упоминать о том, что вообще-то нужно внимательно честь Discord Privacy Policy, в которой вполне себе английским или русским по белому написано, что Discord собирает всё, что вы ему отправляете. В том числе и всю вашу переписку, обратите внимание. И совершенно не обещает её шифровать и вообще как-то беречь её конфиденциальность от самих себя. И есть ряд сценариев, в которых эта собранная информация вполне может уйти куда-то, куда вам не очень хочется, чтоб она ушла. И нужно оценивать эти риски.
Что такое threads в дискорде
Threads are a new Discord feature. Threads can be thought of as temporary sub-channels inside an existing channel, to help better organize conversation in a busy channel.
Threads have been designed to be very similar to channel objects, and this topic aggregates all of the information about threads, which should all help to make migrating very straightforward.
Threads are only available in API v9. Bots that do not update to API v9 will not receive most gateway events for threads, or things that happen in threads (such as Message Create). Bots on APIv8 will still receive gateway events for Interactions though.
The list of gateway events that may be dropped includes, but is not limited to:
Since threads are a new type of channel, they share and re-purpose a number of the existing fields on a channel object:
Additionally, there are a few new fields that are only available on threads:
Public & Private Threads
Private threads behave similar to Group DMs, but in a Guild. Private threads are always created with the GUILD_PRIVATE_THREAD type and can only be created in GUILD_TEXT channels.
Active & Archived Threads
Besides helping to de-clutter the UI for users, archiving exists to limit the working set of threads that need to be kept around. Since the number of archived threads can be quite large, keeping all of them in memory may be quite prohibitive. Therefore guilds are capped at a certain number of active threads, and only active threads can be manipulated. Users cannot edit messages, add reactions, use application commands, or join archived threads. The only operation that should happen within an archived thread is messages being deleted. Sending a message will automatically unarchive the thread, unless the thread has been locked by a moderator.
Because of this constraint, the gateway protocol is designed to ensure that bots are able to have an accurate view of the full set of active threads, but archived threads are not synced up-front via the gateway.
Threads do not count against the max-channels limit in a guild, but there will be a new limit on the maximum number of active threads in a guild.
Threads generally inherit permissions from the parent channel. If you can add reactions in the parent channel, you can do that in a thread as well.
Private threads are similar to Group DMs, but in a guild: You must be invited to the thread to be able to view or participate in it, or be a moderator ( MANAGE_THREADS permission).
Finally, threads are treated slightly differently from channels in the gateway protocol. Clients will not be informed of a thread through the gateway if they do not have permission to view that thread.
Each thread tracks explicit membership. There are two primary use cases for this data:
Syncing for the current user
Syncing for other users
Editing & Deleting Threads
Threads can be edited and deleted with the existing PATCH and DELETE endpoints to edit a channel.
Threads do not explicitly set the nsfw field. All threads in a channel marked as nsfw inherit that setting though.
Threads introduce a few new message types, and re-purpose some others:
There are four new GET routes for enumerating threads in a specific channel:
Webhooks can send messages to threads by using the thread_id query parameter. See the execute webhook docs for more details.
Additional context on the the THREAD_LIST_SYNC and THREAD_CREATE dispatches
While threads are mostly similar to channels in terms of structure and how they are synced, there are two important product requirements that lead to differences in how threads and channels are synced. This section helps explain the behavior behind the Thread List Sync and Thread Create dispatches by going over those problems and how they are solved.
The two product requirements are: The gateway will only sync threads to a client that the client has permission to view, and it will only sync those threads once the client has «subscribed» to the guild. For context, in Discord’s official clients, a subscription happens when the user visits a channel in the guild.
As mentioned, these lead to a couple of edge cases that are worth going into:
Gaining access to a private thread
When a client is added to a private thread, they likely don’t have that private thread in memory yet because of the product requirement that we only sync threads you have permission to view. Private threads are only synced to you if you are a member or a moderator. To solve this, whenever a user is added to a private thread, the gateway also sends a Thread Create dispatch. This ensures the client always has a non-null value for that thread. Note: This is also sent even if the user is a moderator, and thus would already have the channel in memory, mainly for simplicity purposes.
Gaining access to a public thread
When a client is added to a public thread, but has not yet subscribed to threads, they might not have that public thread in memory yet. This is actually only a problem for Discord’s official clients, and not for bots. The gateway will auto-subscribe bots to all thread dispatches and active threads on connect. But Discord’s clients only receive threads that are active and they have also joined on connect in order to reduce the amount of data needed on initial connect. But this means when a user with the official client is added to a thread, that thread now becomes an «active-joined» thread and needs to be synced to the client. To solve this, whenever a user is added to any thread, the gateway also sends a Thread Create dispatch.
Gaining access to a channel
When a client gains access to a channel (example: they gain the moderator role, and thus now they have more channels they can view), they won’t have any of the threads in memory for that channel (since the gateway only syncs threads that the client has permission to view). To solve this, we send the Thread List Sync dispatch to a client when they gain access to a channel! This dispatch includes a channel_ids array, which is the id of all the channels whose threads are being synced. This field can be used to first clear out any active threads whose parent_id is in the channel_ids array, and then ingest any threads that were in the dispatch.
Losing access to a channel
When a client loses access to a channel, the gateway does not send them a Thread Delete event or any equivalent. They will still receive an event when this happens, it just will not be a thread-specific event. Usually the event wil be Guild Role Update, Guild Member Update or Channel Update. It will be some event that caused the permissions on a channel to change. So if a bot wanted to simulate a «lost access to thread» event, it is entirely possible, albeit quite complicated to handle all cases correctly. Under the hood, Discord’s clients actually don’t worry about this detail. Instead, when performing an action, the client checks permissions first (which implicitly checks if the client has access to the parent channel too, since threads inherit permissions), that way even if the client has some stale data, it does not end up acting on it.
Additionally, when a client loses access to a channel they are not removed from the thread. Users may want to temporarily shut down access to a server or channel. Removing someone from all threads when that happens would not be a good experience, so we’ve chosen not to go that route. Users will still be reported as members of a thread, even if they no longer have access to the parent channel. They will not receive new gateway events for those threads though, with one exception: If a client is removed from a thread after losing access to the parent channel, they will still receive a Thread Members Update dispatch.
Unarchiving a thread
Discord’s clients only load active threads into memory on start. So when a thread is unarchived, there is no guarantee that the client has either the thread or whether they are a member, in memory. As such, the Gateway sends a Thread Update first, which contains the full channel object. And then sends a Thread Member Update to each member of the thread, so those clients know they are a member, and what their notification setting is. This event is not that valuable for bots right now, but is going to be received by bots, so is documented here none the less.
Discord Slash API + Yandex Cloud Functions = ♡
Добрый день. Многие знают, что программисту приходится следить за развитием технологий, даже тех, которые не касаются его текущего стека. Ну, или ему это доставляет удовольствие, которое он оправдывает необходимостью держать руку на пульсе. Так обычно зарождаются разнообразные домашние проекты. Я решил свести в один пост свои наработки по написанию Node.js-бота для Discord Slash API с Serverless подходом в Yandex Cloud. Использование готовых библиотек сведено к минимуму.
Discord?
Discord — это многим известный мессенджер, бесплатный до определённых пределов. Он позволяет без особых технических навыков построить коммьюнити по какой-то теме. В основном, конечно, это геймерские сообщества, именно так себя Discord и позиционирует — встроенная функциональность для трансляции игр и прочие навороты. Ими, впрочем, дело не ограничивается — на Хабре пробегали статьи про жизнь небольших контор в этом мессенджере, также там заседают алготрейдеры с «Реддита» и много кто ещё. В определённой степени эта популярность вызвана открытым API для написания ботов. Как правило, в любом сообществе администраторы создают 1–2 канала для совместного прослушивания музыки, игр в простые текстовые развлечения — атмосфера IRC начала нулевых.
В настоящий момент существует два API для ботов на этой платформе. Одно, ставшее классическим, основано на вебсокетах. Второе Discord открыл в конце 2020 года — и им можно пользоваться на чистом REST.
Изначально я наткнулся на статью про Python и AWS, но просто скопировать её было бы слишком скучно для понимания и погружения, поэтому пришлось читать документацию самостоятельно.
Discord Slash API?
Коротко о разнице в подходах между основным WebSocket-протоколом и Discord Slash API для тех, кто уже писал своих ботов, — на вебсокетах можно (и нужно) слушать все сообщения в чате, независимо от того, упоминали там вашего бота или нет. Это открывает широкие возможности для взаимодействия по сбору статистики, для модерирования контента, для описания взаимодействия с пользователями в свободной форме, даже без явного упоминания, и т. д. Боты же, реализующие Discord Slash commands, получают в запрос только команду, написанную пользователем в специальном формате, но не слышат остальной трёп в канале. Эта разница отражена в названии взаимодействия — команда должна начинаться со слеша, и синтаксис выглядит привычным для многих мессенджеров — например, `/дай фотку:котика`. Параметры команды могут быть перечисляемыми. Клиентское приложение подскажет пользователю доступные варианты и явно обозначит, что это команда, а не простое сообщение в чат.
Базовый сценарий:
Начнём с простого — заставим эту связку минимально работать. Нужно отвечать на команду
/дай с параметром фотку: соответствующей картинкой. Варианта будет три — котик, собакен или случайная из двух.
У Discord (в отличие от Telegram) довольно разухабистая система авторизаций, проверок и перекрёстных страниц, по которым надо пройти, чтобы все участники взаимодействия получили свои права в нужном объёме. Общением с @Botfather дело не ограничивается.
Сначала идём на портал разработчика и создаём новое приложение. На этой странице нам пригодятся поля APPLICATION ID и PUBLIC KEY. На вкладке Oauth2 нужно скопировать CLIENT SECRET, он тоже пригодится.
С помощью этих данных можно получить временный Bearer token, который позволяет авторизовываться на некоторых служебных эндпоинтах. Получим его:
CLIENT SECRET вводим весто пароля в интерактивном режиме.
Ответом будет примерно такой JSON:
Из ответа надо запомнить уже поле access_token. Обратите внимание, что scope — тоже значащее поле. Оно определяет, какие права будут у выданного нам токена. Перечисленных в примере хватит для дальнейшей работы.
Следующий нюанс — Slash-команды можно регистрировать глобально или в рамках одного сервера. Если ваш бот большой, серьёзный и готовится захватывать мир, глобальный режим — то что нужно. Везде, куда позвали бота, — его команды сразу появятся. На стадии отладки же он не очень удобен, так как изменения команд будут выкатываться до часа. Регистрация команды на одном сервере проходит мгновенно. Дублировать описание синтаксиса описания команды не буду — эта часть хорошо читается в оригинале.
Работать она, конечно же, ещё не будет.
Знания, необходимые для этой, казалось бы, простой подготовительной части, щедро рассыпаны по документации, так что написание первой простейшей версии бота заняло у меня несколько вечеров. Кроме того — таких извращенцев просто мало, в основном эту функциональность используют вместе с основным ботом, висящим на WebSocket с помощью библиотеки discord.js (что, конечно, получается гораздо быстрее), и готовых сниппетов в интернете практически нет.
Пришла пора писать Serverless-функцию, которая будет отвечать на запросы.
Yandex Cloud Functions
Я не буду подробно останавливаться на описании интерфейса консоли Yandex Cloud. Типичный жизненный цикл Serverless-функций — это обрабатывать входящие обращения, иногда уже отсортированные Gateway API, и отдавать результат. Биллинг потом спишет копеечку за время работы функции.
Отдельно оговорюсь, что в интернете я наткнулся на интереснейшее обсуждение реализации бота на стандартном для Discord WebSocket-протоколе, который завязывался на Amazon API Gateway, умеющем преобразовывать каждое WebSocket-сообщение в отдельный вызов Serverless-функции. Yandex API Gateway так пока не может (но планирует смочь, особенно если их потыкает побольше народа). Честно говоря, и слава Эру, иначе я никогда не довёл бы эту статью до конца.
Итак, в консоли Yandex Cloud создаём новую функцию, среда выполнения — Node.js 14, время выполнения — 3 секунды (про него объясню позднее), доступная память — минимальная — 128 МБ.
Начинаем писать мало-мальски работающий код:
Мы объявили функцию, которая будет вызываться при получении REST-запроса по своему случайно сгенерированному постоянному адресу. В параметр event прилетает всё описание запроса — заголовки и тело. Переменная, которую мы возвращаем, описывает, как должен выглядеть ответ, его статус, заголовки и тело.
Бот обязан проверять подпись входящих запросов. Discord при первом сохранении endpoint проверяет, как она реагирует на запрос с некорректной подписью. И если бот не сможет распознать его и ответить 401-й ошибкой — откажется с ней работать. Проверку было решено отдать на откуп готовой библиотеке, помня о первой заповеди самостоятельной реализации аутентификации — «не делай этого».
Рядом с этим файлом нужно создать package.json, положив в него описание проекта, а главное — зависимостей:
После сохранения этого файла на вкладке «Операции» появится запись о том, что все зависимости установлены. Конечно, никто не мешает писать код в любимой IDE, а затем положить его в ZIP и закинуть на сервер со всеми зависимостями — но мне было интересно, как работает этот функционал.
У проверки подписи есть побочный эффект — вы не сможете потыкать свою функцию тестовыми данными, чтобы проверить её работу. Так что при более-менее серьёзной разработке поднимайте отдельную версию функции, которая не столь радикально относится к подписи. А заниматься такой отладкой придётся, потому что Discord не расскажет вам, что пошло не так при общении с ботом. Именно ручная отладка помогла мне понять, что по умолчанию функция отдаёт заголовок text/plain вместо нужного application/json.
Итак, после сохранения можно взять URL функции, зайти в личный кабинет приложения на сайте Discord, вбить его в поле INTERACTIONS ENDPOINT URL и сохранить. Ура. Теперь начнём, наконец, что-то отвечать на саму команду:
Первая итерация закончена, бот работает, выдает одну, вторую или случайную картинку. Конечно, это абсолютно синхронная и лёгкая операция, и отдавать таким образом статику суперпросто. Теперь пойдём дальше — и сделаем нашу функцию асинхронной.
Все, перед кем вставала задача радовать неугомонных пользователей фотографиями животных, наверное, знают про сервисы The Cat API и The Dog API. Это API, отдающее ссылки на фотографии, доступные для использования в проектах, похожих на наш. Большинство подобных сервисов реализуют функцию random и сами следят за актуальностью фотографий в своей базе, что снимает с разработчика множество проблем. Такие сервисы есть почти по любой тематике, и многие из них бесплатны до какого-то количества обращений. Мне вполне хватало этого лимита, так что я приступил к их использованию, всего лишь один fetch-запрос до сервиса. и сразу наступил на грабли того самого ограничения в 3 секунды, про которое говорил ранее. И проблема тут совсем не во времени исполнения функции — хотя, учитывая, что тарифицируют нас за время работы, необдуманно забивать это поле девятками — безусловно, не лучшая идея.
Проблема описана в совершенно другом месте документации Discord и звучит как «Interaction tokens are valid for 15 minutes and can be used to send followup messages but you must send an initial response within 3 seconds of receiving the event. If the 3 second deadline is exceeded, the token will be invalidated». В переводе на русский это означает, что вместе с сообщением о событии мы получаем особый токен, который позволяет реагировать на входящий запрос ещё 15 минут. Но первый ответ должен быть дан за 3 секунды, иначе пользователь увидит сообщение об ошибке, а токен протухнет.
Я не планировал скачивать изображения и считал что «трёх секунд хватит всем», но нет. Во-первых, запросы в нашем несовершенном мире иногда падают по сетевым причинам. Во-вторых, сервисы эти монетизируются крайне условно и геокешинг с CDN в разных странах, как правило, не используют. Запросы отрабатывали, но за 3 секунды можно вылететь.
Кроме того, однажды я попал в ситуацию, когда изображения перестали открываться в чате. Виноват оказался Роскомнадзор: CDN сервиса с котиками попал под блокировку. Сам сервис отдавал ссылку на картинку, я передавал её в чат, а Discord не мог открыть её, так как из России адрес был недоступен. Дополнительная проверка ссылки на доступность (напомню, мы всего лишь пытаемся показывать милые фото котиков) делала перспективы уложиться в 3 секунды более призрачными, особенно в случае повторного запроса.
Решение? Очевидно — создадим ещё одну функцию.
Новый план!
Если делать всё по-взрослому — такой запрос от функции к функции следует передавать, используя брокер сообщений или другие механизмы, которые могут служить триггером для функций в облаке. Мне показалось, что для такого простого и нетребовательного проекта это уже слишком, можно обойтись запросом POST в один конец, не дожидаясь его результата. Я не был уверен, успеет ли этот запрос отработать, не оптимизирует ли его какой-то из внутренних механизмов облака, — но нет, вполне себе рабочий вариант. Конечно, мы не узнаем, дошёл ли запрос и как был обработан — но, повторюсь, на практике в этом месте проблем у меня не возникло или они были пренебрежимо малы.
Медленная функция должна будет отправить результат своей работы методом POST на https://discord.com/api/v8/webhooks/APPLICATION ID/INTERACTION TOKEN — это послужит ответом на первый, служебный ответ быстрой функции.
Изменения в быстрой функции:
В ответ я добавил поле flags, чтобы чуть меньше засорять весь канал лишними сообщениями. Медленная же функция будет радовать результатом своей работы всех.
Работа с точки зрения пользователя:
Итоги
Главный вопрос, который может возникнуть при прочтении: «Зачем?».
Я отвечаю на него: «Чтобы не следить за сервером». Как только Yandex Cloud добавит в Gateway API возможность удержания WebSocket-сообщений — я попробую переписать и WebSocket-бота (который начинает спамить котиками при слишком бурном и не очень цензурном общении в чате) на Serverless.
Иногда нужен контроль, иногда страшно, что функция слишком бодро масштабируется, иногда есть виртуалка, на которой вполне хватит места на ещё-один-докер-с-js-процессом-внутри. Но рано или поздно за этим придётся следить — переносить процесс, данные, добавлять мониторинг, обновлять систему, наконец. Serverless-подход несложен в использовании, не требует ухода после деплоя и очень дёшев при небольших/нечастых нагрузках для домашних проектов.
Кстати, про «дёшево» — это, как правило, второй возникающий вопрос. Посчитаем по прайсу.
При тарификации вычислительных ресурсов (ГБ × час) учитывается объём памяти, выделенный для функции, и время выполнения функции.
На июль 2021 г. 1 миллион вызовов стоит 10 ₽, ГБ*час стоит 3,42 ₽, а исходящий трафик — 0,96 ₽ за гигабайт.
Среднее оплачиваемое время выполнения этих функций (из отчёта Yandex Cloud):
Медленная функция: 1200 мс
Быстрая: 200 мс
Итого: 1,4 с на обработку одного запроса.
Прикинем стоимость миллиона котиков:
3,42 × (128 / 1024) × (1200 / 3600 / 1000) × 1 000 000 + 10 × (1 000 000 / 1 000 000) = 152,5 ₽
Но — приятный подарок — первый миллион запросов, первые 10 ГБ × час в месяц и первые 10 ГБ исходящего трафика не тарифицируются.
Из моей личной практики (на канале в 400 человек, где у бота есть клуб преданных фанатов): он ни разу не вышел в платный режим. Даже с учётом вакханалии на 1 апреля, когда он показывал, а затем оперативно удалял чуть-чуть NSFW-шные картинки, которые «случайно» попали в его базу.
Неважно, что вы делаете — планировщик задач, торгового бота или такой проект на коленке, — прежде чем писать ещё_один_демон_за_которым_надо_следить, подумайте, возможно Serverless подойдёт вам больше.