Я только что вник в эту тему, но, безусловно, считаю, что ответ — да
Благодаря успеху нашего корпоративного сообщества (как среди пользователей, так и внутри компании) команда документации обратилась к нам с просьбой создать систему комментариев для всего сайта documentation.sailpoint.com. Судя по всему, мы сможем реализовать почти всё, что необходимо как минимум:
Встраивание комментариев (функция встраивания)
Также мы хотим использовать разных пользователей для публикаций и применять различные наборы тегов в зависимости от контекста встраивания. Эта функция появится очень скоро:
После этого всё остальное, что хотели команда документации (и моя команда), уже есть в Discourse. Это позволит нам эффективно отделить этот опыт от остального повседневного использования форума, сохраняя при этом возможность для пользователей оставлять комментарии, получать уведомления о ответах и т.д.
Возможность определить, какие пользователи могут и не могут комментировать
Назначение модераторов категорий для соответствующих тем
Скрытие этого множества категорий документации с нашего основного сайта
категория не индексируется поиском
используется компонент темы для скрытия из основного списка категорий
исключено из дайджестов
добавлено в список категорий по умолчанию с отключенными уведомлениями
Удаление комментариев через N дней
Несколько других настроек…
Мне бы очень хотелось увидеть реализацию многих функций, упомянутых здесь!
Цель состоит в том, чтобы позволить пользователям оставлять комментарии на https://documentation.sailpoint.com/, или вас устроит просто встроить комментарии на сайт документации, а пользователям предлагать посещать ваш сайт на Discourse для комментирования статей?
Первое — это функция, которую я с радостью приветствовал бы и очень хотел бы видеть (читай: пожалуйста, реализуйте, CDCK), но второе, по крайней мере, удовлетворяет нашим минимальным требованиям.
На самом деле в ближайшем будущем я планирую изучить идею, при которой Discourse будет предоставлять нашу документацию в формате Markdown (нет, не в темах, а в виде традиционных документов в стиле Markdown). В таком случае комментарии и регистрация для их оставления были бы включены в один пакет. Однако это исследование ещё не началось.
С подходом, над которым я сейчас работаю, технически возможно разрешить генерацию комментариев Discourse прямо на страницах MkDocs, но для этого потребуется использовать серверный фреймворк (Remix, Rails и т. д.) для обслуживания страниц MkDocs. Это позволило бы аутентифицировать пользователей (с помощью DiscourseConnect) на сайте документации, а также использовать базу данных в оперативной памяти для кэширования ранее возвращённых комментариев.
(Редактирование: просто для ясности, я говорю об использовании Discourse в качестве провайдера идентификации для веб-сайта, а не веб-сайта в качестве провайдера идентификации для Discourse. Последний подход работает, но он слишком негибкий для большинства случаев использования.)
Однако это было бы значительным изменением, которое потребовалось бы предложить вашей команде.
Уверен, что с вашей точки зрения было бы проще, если бы это было реализовано полностью внутри Discourse, но также возможно использовать Discourse как систему управления контентом. В этом случае документация в формате Markdown будет генерироваться как обычные темы Discourse. Веб-хуки Discourse будут использоваться для запуска генерации страницы документации на внешнем сайте. На самом деле это основа демонстрационного сайта комментариев Discourse, который я настраиваю.
В этом-то и заключается то, что мне так нравится в этой платформе: у неё есть все основы для того, чтобы (или даже для обоих!) этих вариантов были возможны.
Поскольку эту тему сегодня упомянули, я решил обновить её, добавив выводы, к которым пришёл после работы над этой идеей.
Я по-прежнему считаю, что Discourse мог бы стать хорошей платформой для комментариев по причинам, которые я изложил в первом посте.
Что касается реализации, я думаю, что работа должна проводиться на стороне Discourse — в идеале путём улучшения скрипта встраивания комментариев Discourse. Это можно делать поэтапно.
Технически возможно использовать Discourse в качестве сервера для платформы комментариев, выполняя всю работу на клиенте Discourse (например, плагин WP Discourse), но из-за необходимости синхронизировать состояние между клиентом и Discourse, а также обходить ограничения по частоте запросов, задача становится слишком сложной. Это определённо сложнее, чем то, чем я хотел бы заниматься и поддерживать.
Несколько постов в этой теме указывали, что люди были бы заинтересованы просто в возможности создавать комментарии в Discourse на сайте блога. С моей точки зрения, это не лучшее решение, но это уже можно реализовать с помощью API Discourse. Сложности возникают при попытке создать полноценную систему комментариев, где пользователи могли бы взаимодействовать с комментариями в Discourse на веб-сайте так же, как они ожидают взаимодействовать с комментариями на типичном новостном портале.
Исходя из моего опыта работы с ActivityPub и WP Discourse, я считаю, что двусторонняя комментация через встроенный JavaScript достижима. Скрипт встраивания будет включать следующее:
Неаутентифицированное «чтение», работающее аналогично текущему JS-встраиванию (с некоторыми оптимизациями).
Удалённый клиент (то есть браузер пользователя) регистрирует клиент API-ключа пользователя, специфичный для сессии пользователя, и сохраняет соответствующие данные в локальном хранилище браузера.
Пользователю предлагается «Войти, чтобы комментировать».
Пользователь проходит аутентификацию (через Discourse), чтобы получить ключ API сессии пользователя, который сохраняется в локальном хранилище браузера.
Каждое действие (комментарий, лайк и т. д.) напрямую отправляется на выделенную конечную точку с соответствующими мерами безопасности, обработкой и управлением задачами.
При правильном бюджете я думаю, что смогу подготовить v1 к производству и интегрировать его с discourse/discourse за 6–8 месяцев. После первоначального релиза я мог бы сделать следующее:
Добавить явную поддержку WordPress, Ghost и других выбранных платформ.
Постарайтесь реализовать это так, чтобы это было понятно и удобно для нетехнических пользователей. Существующие платформы, такие как Disqus и комментарии Facebook, вероятно, могут служить хорошими примерами.
Дополнительные варианты аутентификации:
сайт-клиент становится клиентом DiscourseConnect. Это относительно просто реализовать, но требует добавления кода на стороне сервера на сайт-клиент.
пользователи входят напрямую в Discourse через iframe
Моя неохота разрабатывать это исключительно на стороне клиента была связана с опасениями относительно масштабируемости системы. По сути, мне приходилось выстраивать запросы к API в очередь и обрабатывать ответы от этих запросов. Это не казалось достаточно надёжным решением для работы, например, с 1000 одновременными пользователями. У меня были бы аналогичные опасения и при использовании подхода с JavaScript-виджетом, но по другим причинам. Однако я полагаю, что с этим будет гораздо проще справиться, чем пытаться синхронизировать всё на стороне клиента.
Вчера я ещё раз глубоко обдумал этот вопрос, так как тема была поднята (поэтому я в итоге написал здесь). Я считаю, что решение только на стороне клиента (т.е. JavaScript-виджет) — единственное, которое действительно имеет смысл в данном случае. В противном случае мы фактически говорим о множестве реализаций, специфичных для каждой платформы, у каждой из которых есть свои проблемы.
Вы правы, что проблемы с конкурентностью и нагрузкой существуют. С ActivityPub есть значительные проблемы с нагрузкой и конкурентностью, поскольку один пост ActivityPub может открыть вас для множества входящих и исходящих запросов к Федиверсу и от него. В этом контексте это может быть даже немного проще, так как удалённые клиенты контролируются. Более того, в данном случае проблемы с конкурентностью и нагрузкой возникают в основном на стороне сервера (т.е. на стороне Discourse), и, хотя они существуют, я думаю, их можно решить с помощью фоновых задач, кэширования и мьютексов. Но да, это важные вопросы, которые необходимо учитывать.
Честно говоря, моя главная забота здесь — это сроки.
Composer v2 вот-вот выйдет. Было бы безумием начинать это приключение и не использовать наш новый Composer, но нам предстоит огромная работа, чтобы сделать его применение в легковесном приложении реалистичным.
Я считаю, что правильным решением будет понаблюдать за развитием нового Composer в течение 2–3 месяцев, а затем вернуться к этому вопросу.
Я думаю, это можно сделать параллельно. Вам нужно внести 2 изменения в Discourse.
Кнопка «Ответить» должна быть видна незарегистрированным пользователям.
А когда незарегистрированные пользователи нажмут на эту кнопку, должно отобразиться следующее:
Далее вам нужно разобраться, как использовать вставку комментариев. Скорее всего, это потребует небольших изменений в коде, а не значительных усилий.
Интересно, есть ли ещё интерес к разработке этой функции, теперь, когда вышел Composer v2. Голосую за то, что это всё ещё то, что я бы хотел увидеть и использовать.
Также, должен ли iframe иметь фиксированную высоту, или возможно настроить его адаптацию под количество комментариев, как это делает текущий встраиваемый элемент?
Ещё один вопрос: будет ли код GTM/Analytics загружаться или блокироваться внутри этого встраиваемого элемента? Идеальный вариант — не загружать его, иначе статистика будет дублироваться (блог и Discourse будут одновременно вызывать два просмотра страницы).
Я объединил свою экспериментальную работу по встраиванию полных страниц, поэтому теперь её можно протестировать, если вы хотите попробовать.
Вам нужно:
Обновиться до последней версии
Включить скрытую настройку embed_full_app
Добавить fullApp: true в фрагмент JS-кода, который настраивает встраивание на вашей странице
Процесс входа всё ещё не отлажен для пользователей, которые ещё не вошли в систему, но в вашем сообществе, где у людей уже есть действительные куки, это может отлично подойти.
Дайте знать, как всё прошло — это поможет нам определить дальнейшие шаги.
→ Вместо загрузки полного форума происходит переход по адресу embedUrl, затем перенаправление (на моей платформе требуется вход), и создаётся мусор-тема с URL перенаправления в качестве заголовка.
Поведение как у обычного виджета комментариев — параметр fullApp: true полностью игнорируется.
Обязательно ли указывать discourseEmbedUrl даже в режиме fullApp?
Если да, то можно ли предотвратить создание тем и просто отрендерить полный форум?
Буду очень признателен за любую помощь.
Готов предоставить дополнительные детали или протестировать что угодно.
