Бывало ли у вас так, что вы придумали у себя в голове идеальное приложение, в котором есть все вам необходимое (ну или хотя бы какой-то обязательный минимум)? Вот вы нашли приложение, которое должно решать те задачи, что вы себе придумали, но как только принялись его проверять в действии, пришли к выводу, что все совсем не так радостно.
«Ну ладно, это же опенсорс! Значит можно попробовать что‑то с этим сделать своими силами. Заодно и внести посильный вклад в развитие этого продукта. Что может быть лучше?» — сказали вы себе. Но реальность оказалась иной. Код для непрограммиста оказался довольно сложный, принятая разработчиками архитектура приложения также вызывает вопросы (конечно, скорее всего только у меня) и т. д. Частично отсюда и пресловутая «лень» в заголовке.
К чему это я? Начну с небольшой предыстории.
Истоки
На заре становления меня самого в качестве айтишника (более 15 лет назад) для рабочего общения сотрудников в бюджетных и не только организациях основным средством была (да собственно до сих пор и остается) электронная почта. Однако потребность общения в реальном времени также всегда присутствовала (не только телефон или при встрече). Мессенджеры — наше всё. Протоколов и приложений народилось за последние 20 лет великое множество. Примеры приводить не буду — все всё и так знают.
Скажу лишь, что первым протоколом и приложением («человек и пароход»©) для рабочей быстрой переписки («корпоративного чата», как его формально называют) в моей практике стал jabber (xmpp). Без каких‑либо наворотов — просто приложение, устанавливаемое и настраиваемое вручную на компьютерах организации и умеющее на тот момент (год этак 2009, вроде бы) только текст и смайлики (и то разнообразия особого не было, как и анимации). Сервером был ejabberd под FreeBSD 6, если мне память не изменяет, но могу ошибаться — давно было.
Чуть позднее уже на другой работе нашлась другая реализция сервера — Openfire, а в качестве клиента ее «родной» Spark. Данная связка оставалась в моей рабочей практике незыблемой буквально до 2023 года. Почти всё необходимое она умеет: LDAP, архивирование, многочисленные интеграции, поддержка клиентом даже самых устаревших ОС в лице Win XP и Win 7, в конце концов в развертке и настройке это всё еще и очень не сложная история. Казалось бы на том можно и остановиться. Но однажды в организации появился облачный сервер на базе Nextcloud со своей экосистемой...
Самоделкин
Стала очень заманчивой идея максимально интегрировать функционал всего (или почти всего), что есть в организации, в эту самую экосистему и корпоративный чат не стал исключением. Темой этой статьи стал именно он - Nextcloud Talk (ранее известный как Spreed). О других интеграциях и костылях сделанных и успешно работающих я (может быть) расскажу в другой раз.
Сейчас же хочу сразу хочу уточнить, почему выбор пал именно на Talk. Собственно в организации уже был работоспособный упомянутый ранее Openfire с раскиданным групповыми политиками по рабочим местам пользователей клиентом Spark. Поначалу чисто для пробы в работающем Nextcloud'е был установлен и настроен JavaScript XMPP Chat — OJSXC. Но степень интеграции в Nextcloud оказалась довольно ограниченной. Кроме того донимали многочисленные недоработки.
Затем, в перерывах между работой над интеграцией Roundcube и тестированием RocketChat я решил посмотреть, а что собственно умеет Talk. Как оказалось, умеет он настолько достаточно, что теоретически может выступить неплохим заменителем не только корпоративного чата, но и уже работающей со во времен начала пандемии системы ВКС Bigbluebutton (при условии, что администратор осилит настройку быстрого backend сигнального сервера — у меня к слову уже есть готовый рецепт для быстрой развертки прямо в докер). Сразу стало интересно, а можно ли «вытащить» Nextcloud Talk из браузера и сделать так, чтобы он работал на рабочих местах сотрудников как приложение мессенджер, типа Spark. Поскольку по роду деятельности я всё‑таки системный администратор, также заинтересовал вопрос минимального участия пользователей рабочих мест в его настройке, т. е. в идеале, чтобы распространить приложение на места, выдать какой‑то единый конфиг для клиента и не запрашивать у пользователей домена логин и пароль (SSO).
Естественно первым делом я нашел официальный десктопный клиент для Talk, но разочаровался в нем сразу, т.к. на тот момент будучи альфа версией в нем отсутствовал самый на мой взгляд важный для корпоративного (да и не только корпоративного) мессенджера функционал. Забегая вперед могу сказать, что на данный момент (за почти 2 года с момента, как я его нашел) этого функционала так и не появилось. Например, элементарный и очень важный счетчик непрочитанных сообщений на иконке приложения (в трее и/или панели задач ОС) до сих пор стабильно откладывают «на потом», несмотря на многочисленные просьбы.
Конечно, я ознакомился с кратким руководством разработчика для приложения, решил сделать форк проекта и попробовать поразбираться. Тем более, что про Electron наслышан, но ничего еще раньше на нем не делал. Я быстро понял, что что‑то не так, когда увидел, что с условного `npm start` до момента появления главного окна browserWindow проходит почти минута, а то и больше. Стало ясно, что помимо и без того тяжелых зависимостей, которые тянет с собой electron (по сути целый браузер Chrome), разработчики предлагают еще и весь исходный код Talk тянуть, который и так работает на стороне сервера, с которым должен работать клиент. И я решил попробовать подойти к разработке с другой стороны.
Небольшое отступление. Я понимаю, что есть определенные правила, рекомендации и best practices при разработке приложения на electron касательно безопасности при открытии в десктопном окружении кода с удаленного сервера, но держа в уме, что приложение делаю для работы внутри организации с кодом своего полностью подконтрольного сервера Nextcloud я решил, что для себя можно этими вещами пренебречь. Если кто‑то со мной не согласен — можно в комментариях, если они будут, об этом мне не упоминать — я всё понимаю. Кто хочет воспользоваться — воспользуется. Страшный исходный код открыт.
Итак. Потыркавшись в официальное приложение и приняв во внимание, что по сути никакого базового функционала настольного мессенджера в нем нет, я решил попробовать сделать свой вариант сразу с теми минимальными вещами, с которыми это приложение можно было бы использовать в любой организации с сервером Nextcloud и доменом. А чтобы не тянуть весь исходный код, я решил сделать приложение wrapper, которое взаимодействует с удаленной страницей Nextcloud и, при необходимости, загружает локальный js код из клиента и выполняет его в browserWindow с загруженной с удаленного сервера Nextcloud страницей Talk. Еще раз подчеркну: убедитесь, что не используете его с неизвестным вам потенциально небезопасным сервером Nextcloud.
Перечислю функции настольного приложения, которые я поставил себе в качестве целей при разработке NC Talk Electron и уже пришел к ним в текущей версии (0.4.1-alpha на момент написания статьи):
возможность автоматически загружаться при входе пользователя в ОС
возможность запускаться в свернутом виде с иконкой в трее
возможность использовать логотип удаленного сервера Nextcloud в качестве иконки
хранить настройки в базовом понятном текстовом формате json
хранить логин и пароль в системном trusted store (за это отвечает модуль npm keytar)
возможность автоматически открывать соответствующий чат при получении сообщения, если приложение скрыто в трей или не в фокусе
отображать счетчик непрочитанных сообщений на иконках в трее (на всех поддерживаемых платформах) и панели задач (кроме Linux — там множество DE и под все подстроиться сложновато)
возможность автоматически использовать настроенный в Nextcloud openid SSO — клиент запускается и входит без ввода пароля пользователя (ставьте «+» в карму, чтобы смотивировать меня на написание гайда по настройке)
В ближайших планах, если будет время и силы, сделать возможность работать сразу с несколькими серверами Nextcloud (multi account) и переработать всплывающие уведомления (сейчас используется штатная система Nextcloud с некоторыми проблемами).
Подробнее о системных требованиях, параметрах конфигурации и информация для разработчиков — в README на github.
Кстати, насчет системных требований — есть одна существенная для кого‑то ложка дегтя: приложение несовместимо с версиями Windows старше Windows 7 — ограничения Electron версии 22.3.27. Собственно ради «семерки» тоже пришлось поколдовать с зависимостями, но пока она поддерживается. Это главный минус по сравнению со Spark.
Эпилог
Напоследок снова хочу отметить, что приложение делается в первую очередь для себя, а этот опус решил написать для того, чтобы немного добавить (или поубавить) мотивации к его развитию — благо развивать там можно еще много чего, всё‑таки альфа‑версия. Бесплатными тестерами по сути являются сотрудники на трех разных рабочих площадках в разных организациях с более, чем 300 сотрудниками суммарно. Это не считая тех, кто вполне возможно воспользовался приложением самостоятельно. Но жалоб не так, чтобы много. Основная их масса пришлась на самое начало разработки. Если кто‑то из читателей хабра найдет приложение полезным — буду рад поставленной звездочке. =) На лавры тру/мидл/сеньор программиста (нужное подчеркнуть) я не претендую — исходный код говорит сам за себя.
Спасибо всем за внимание!
