Бывало ли у вас так, что вы придумали у себя в голове идеальное приложение, в котором есть все вам необходимое (ну или хотя бы какой-то обязательный минимум)? Вот вы нашли приложение, которое должно решать те задачи, что вы себе придумали, но как только принялись его проверять в действии, пришли к выводу, что все совсем не так радостно.
«Ну ладно, это же опенсорс! Значит можно попробовать что‑то с этим сделать своими силами. Заодно и внести посильный вклад в развитие этого продукта. Что может быть лучше?» — сказали вы себе. Но реальность оказалась иной. Код для непрограммиста оказался довольно сложный, принятая разработчиками архитектура приложения также вызывает вопросы (конечно, скорее всего только у меня) и т. д. Частично отсюда и пресловутая «лень» в заголовке.
К чему это я? Начну с небольшой предыстории.
Истоки
На заре становления меня самого в качестве айтишника (более 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 сотрудниками суммарно. Это не считая тех, кто вполне возможно воспользовался приложением самос��оятельно. Но жалоб не так, чтобы много. Основная их масса пришлась на самое начало разработки. Если кто‑то из читателей хабра найдет приложение полезным — буду рад поставленной звездочке. =) На лавры тру/мидл/сеньор программиста (нужное подчеркнуть) я не претендую — исходный код говорит сам за себя.
Спасибо всем за внимание!
