Вопросы о технической архитектуре Discourse

Разработка
1

Привет

Давным-давно я был технарем, но сейчас уже нет. Я уже упоминал в другом месте, что меня интересует дизайн цифровых сообществ. Социология, построенная на технологиях.

Я не знаю, как устроена архитектура Discourse, но понимаю, что в ней есть темы и плагины. Если есть какие-то другие компоненты, о которых я не знаю, прошу поправить.

Помогите, пожалуйста :slight_smile:

Я пытался искать информацию о паре (темы/плагины) разными способами, но не находил ничего, что могло бы сказать: «Вот 101-й уровень: что и зачем». Например: есть слой представления, слой хранения и процесс выбора между ними, который использует эту информацию для установления контекста и переключения от одного к другому. Из коробки вы получаете X, Y и Z. Плагин — это… любой плагин в каталоге загружается при запуске процесса сервера (или чего-то подобного); они подключаются к UI/бэкенду/фронтенду через…; существующие плагины — это… Тема влияет на слой представления (?) из коробки и плагины следующим образом…

Существует ли такое описание, на которое кто-то мог бы дать мне ссылку, которое провело бы меня от нуля к достаточному пониманию, чтобы найти то, что уже существует, и иметь достаточно знаний для творческого мышления?

Потому что

тогда я смогу использовать их как концептуальные строительные блоки при проектировании сообществ для разных целей.

Меня интересует:
— можно ли «закалить» Discourse, чтобы он соответствовал стандартам #медицинского уровня? Нет, я пока не знаю, что это за стандарты в конкретной юрисдикции, но знаю, что они будут необходимы в зависимости от целей и различаться в разных регионах.

— интеграция с инструментированными средствами реабилитации и кодирование для извлечения анонимизированных данных (gdpr compliant) о прогрессе и метриках эффективности, чтобы получить данные об улучшениях для исследований.

— как лучшие посты могут подниматься наверх, как сливки, чтобы новые пользователи не сталкивались с UX Discourse, который кажется чужим в теме, где они только что осознали острую потребность, находясь в состоянии дезориентации, перед лицом тысяч постов и тем, имеющих только академическую иерархическую структуру, не понятную им на интуитивном уровне…

Иерархические структуры обычно лучше подходят для поиска тем, если сначала можно сделать паузу и применить шаблон поиска, но обычно они поддерживают только поиск в глубину. Discord, похоже, является примером: предполагается, что пользователь уже знает предмет. Это можно немного смягчить с помощью хештегов — это ещё одна тема в моём списке для чтения.

Возможно, какие-то решения с ИИ-ботами закрывают этот пробел? Ещё один пункт в моём списке…

Также я просматриваю несколько видео через блог с @jonobacon и, возможно, смогу задавать более осмысленные вопросы после их просмотра.

Чтобы творчески мыслить в контексте Discourse, мне нужно лучше понять, какие компоненты и интерфейсы существуют.

Не могли бы вы дать мне ссылки на нужные материалы? :slight_smile:
Заранее спасибо.

2

Просмотр существующих плагинов, тем и компонентов тем может дать вам представление о том, какие возможности кастомизации доступны:

3

:wave: Привет @51mon — если вы заинтересованы в разработке форума Discourse, эта информация может быть вам полезна. :slight_smile:

4

Спасибо :slight_smile:

Кажется, вы дали мне словарь, когда я надеялся получить руководство по тому, как читать ! — не найдётся ли у вас более мягкого введения в тему того, что это за вещи и как они работают, а не того, что они делают :-)?

В ваших ссылках много информации, но нет общего обзора, объясняющего архитектуру дискурса — меня сейчас меньше волнуют возможности, предоставляемые плагинами и т. д. — я всё ещё пытаюсь разобраться, что они собой представляют на самом деле

5

Спасибо, я посмотрю :slight_smile:

Я немного сомневаюсь, так как они помечены как «разработка…», а мне не интересно писать код — я хочу понять архитектуру.

Я посмотрю, потому что пока не очевидно, подойдут ли эти тексты для моих нужд (надеюсь на лучшее).

Я дам вам знать — если, конечно, у вас нет других предложений :). ?

6

@51mon Я полагаю, вы изучили эти материалы?

7

Я этого не знал :slight_smile: Спасибо

~~ "~~
[[Правки]]

Ой! Первая ссылка ведёт к заголовку с 15 темами.

Вторая и третья ссылки — это коммерческие страницы, хотя, по крайней мере, они состоят из одной страницы. Однако там представлены списки функций, а не архитектурные описания.

И ещё раз ой: я даже не уверен, что представляет собой последняя ссылка, кроме как приглашение войти в систему на try.discourse.org. Там есть темы с более чем 100 записями, плюс одна тема с более чем 1000 записей —

нет карты. Это должно быть похоже на то, как чувствовал себя Кук, когда впервые увидел Австралию, а затем днями плыл вдоль её берегов.

Правка
Список функций

На странице перечислен длинный список вещей. Некоторые из них носят концептуальный характер. Когда название относится к концепции, которая не описана, это лишь сообщает о существовании чего-то, но не даёт понимания того, что это такое. Так что я знаю из списка функций, что их много :slight_smile: , но у меня нет представления о том, что именно я могу делать с помощью многих из названных функций.
Это хорошо для демонстрации широты возможностей и служит хорошим напоминанием для тех, кто уже знаком с системой, но трудно для тех, кто ищет понимания.
Кроме того, из этого списка функций я не могу понять, являются ли они плагинами, темами, стандартными функциями, уникальными для Discourse или общими для всех платформ.
Я не утверждаю, что страница должна быть именно такой на данном этапе; я просто делаю заметки, потому что мне предстоит исследовать целый континент. То, о чём спрашивал мой автор оригинального сообщения, — это изображение Земли, сделанное с Луны, а пока я даже не смог подняться на мачту HMS Endeavor :grin:

Третья ссылка «Что такое Discourse» представляет собой смесь рекламного текста и других материалов. Она также не содержит информации об архитектуре — я не говорю, что она должна это делать, но раз этого нет, то это не то, что я ищу.
Кроме того, это описание не совсем кажется мне правдивым. Например, утверждается, что в Discourse избавились от сложности, однако цвет красный в интерфейсе меняется в зависимости от количества лайков по сравнению с количеством сообщений. Это очень изощрённый элемент интерфейса. Кроме того, независимо от того, нажмёте ли вы в списках непрочитанных сообщений на заголовок, количество ответов или на третье поле, которое я не знаю, как назвать, вы будете перенаправлены в разные места внутри темы. Все эти изменения в пользовательском опыте неочевидны, не объявлены и не сигнализированы, и пока вы не узнаете об их существовании в интерфейсе, они будут сбивать с толку.

8

Честно говоря, @51mon, я не думаю, что понял ваш вопрос. Не могли бы вы сформулировать его проще, и я постараюсь как можно лучше ответить вам.

9

Это очень любезно с вашей стороны, @JammyDodger — я обязательно сделаю это, как только смогу, но пока не могу.

Мне казалось, что в моём первом сообщении я выразил всё достаточно ясно, но, очевидно, это не дошло до вас (вернее, до ваших глаз!).

Давайте попробуем ещё раз.

Если бы мы оба стояли и смотрели на автомобиль, мы могли бы вести разговор вроде: «Вы можете сесть в него, и он отвезёт вас в супермаркет или на пляж». Или же мы могли бы обсуждать: «У него есть колёса и двигатель, работающий на бензине или от батареи, рулевое управление и тормозная система».

Разговор о тормозах, указателях поворота и о том, включается ли автоматически внутреннее освещение, — это разговор разработчиков. А разговор о поездках на пляж, о том, как возить детей в школу по утрам, о том, поместится ли в багажник инвалидная коляска или можно ли буксировать прицеп, — это пользовательская дискуссия, граничащая с технической. Чтобы буксировать прицеп, нужно установить сцепное устройство, так как его нет в стандартной комплектации. При покупке автомобиля вы выбираете цвет: белый, серый, чёрный или, возможно, синий. Это разовые решения — возможно, в контексте Discourse они относятся к административным настройкам.

Теперь один из многих аспектов, которые меня интересуют: смогу ли я использовать Discourse для поддержки сообщества, где информация, хранящаяся где-то между административными данными, накопленными постами участников, идентификаторами пользователей и т. д., должна соответствовать медицинским стандартам защиты данных (конфиденциальность, целостность и доступность — CIA). Но я не могу оценить этот вопрос, пока не узнаю, какова базовая архитектура.

Если это всё ещё не прояснило ситуацию, вам придётся подождать, пока я изучу все материалы, которые мне прислали, чтобы задать вопрос, понятный тем, кто сможет на него ответить, поскольку сейчас я не могу сформулировать его лучше.

Спасибо! :slight_smile:

Это путешествие открытий, и я согласен, что оно займёт некоторое время. Когда я сделаю необходимые открытия, я, скорее всего, оформлю их в виде статьи и верну их сообществу здесь, в надежде, что они помогут другим в будущем.

10

Боюсь, это не очень прояснило ситуацию. :slight_smile: Надеюсь, кто-нибудь ещё подключится и даст вам то, что нужно. :crossed_fingers:

Вы уже создали форум, чтобы попробовать себя в нём? Это может помочь вам исследовать свои идеи и понять, что возможно.

11

Привет, @51mon.

Я подозреваю, что часть проблемы кроется в метафорах. Всё, что кто-то пишет, часто понятно автору. Однако другим может быть трудно это понять.

Итак… продолжаем:

Discourse Meta по своей сути разработан как базовый фреймворк для сообществ.

Он предоставляет базовую основу… которая из коробки выглядит довольно блекло.

Учитывая нашу с вами возрастную группу, вы, возможно, были вовлечены в Electronic BBS на DOS или знали о них.

Довольно много из них были производными от Telegard BBS, также известной как Telegard Hacks. (немного отвлеклись…)

Возвращаемся к теме.

Итак, вы хотите создать форум Discourse Meta для…

Это ваша отправная точка. Сядьте и определите идею: какова цель вашего сообщества и что вы хотите предложить с точки зрения функций и возможностей.

Затем сделайте шаг назад.

Чтобы получить более чёткое представление о том, куда можно двигаться. Изучите список сообществ, уже использующих Discourse. На данный момент у меня нет под рукой ссылки. Изучение существующих сообществ даст вам представление о том, чего можно достичь… и насколько похожи некоторые сообщества, и насколько они могут отличаться по масштабу и функциям.

Отсюда вы можете записать функции различных сообществ, которые вы хотите включить в идею своего сообщества.

Вы можете решить, хотите ли вы платный хостинг, который упростит качество жизни, или полный контроль и самохостинг для тотального контроля и мощной расширяемости, позволяющей выбирать любые плагины. Но это потребует затрат на самостоятельное обслуживание VPS.

В любом случае вам нужно будет изучить, что потребуется для обеспечения доступности функций и возможностей, необходимых для проектирования вашего сообщества.

Итак, давайте проведём мысленный эксперимент. Предложите пример идеи сообщества. Мы даже можем взять существующее сообщество и спросить себя, какие #plugin (если нужны), #theme и #theme-component потребуются для реализации того, что есть в этом сообществе?

12

Привет, @Heliosurge
:slight_smile: Забудь про те BBS, которые я помню: NewsNet, запущенный UKC в Кентербери по коммутируемым линиям со скоростью 300 бод, а также сервисы и клиенты на базе NNTP, такие как FreeAgent.

Я полностью согласен, что аналогии и даже просто слова, собранные в предложения, часто лишь отражают понимание, существующее только в голове автора. Даже если они создают понимание у других, нет гарантии, что это понимание совпадает! :slight_smile:

Давайте попробуем так:
Я понимаю, что у Discourse есть серверная часть, содержащая базу данных постов и пользователей; и посты, и пользователи имеют атрибуты и связаны между собой. Это где-то размещено: хост может быть виртуальным, может использоваться сеть доставки контента (CDN) и т. д.

Я понимаю, что на стороне клиента есть слой представления, который использует посты, учётные данные аутентификации пользователя и права доступа, а также ссылки для создания ленты. Я вижу, что философски многие используемые структуры иерархичны. Эта иерархия скрыта множеством механизмов перекрёстных ссылок.

Я предполагаю — и считаю это безопасным предположением — что цветовая схема и прочее, используемые на стороне клиента, привязываются во время выполнения к теме, которую можно заменить, так что при следующем запуске привязка будет к новой теме; при этом контент не меняется, но меняется внешний вид представления и, возможно, даже некоторые функциональные навигационные стилистические компоненты. Но здесь мои представления становятся туманными и спекулятивными.

Я знаю, что существуют компоненты тем, и в настоящее время у меня в голове есть модель, согласно которой комбинация компонентов темы образует тему, но и здесь я немного не уверен. У меня нет чёткого понимания примеров того, что делает компонент темы.

Менее всего я понимаю плагины. Я улавливаю архитектурную часть: они находятся на стороне сервера и, следовательно, работают в запущенном экземпляре, который обслуживает контент. Я не до конца вижу взаимодействие между темой и плагином. Я бы предположил, что если вы расширяете возможности серверной части, то нужно расширять и представление на стороне клиента, но это уже неопределённость в неопределённости.

Также я не знаю, состоит ли полная архитектурная модель из: сервера, программного обеспечения для обслуживания, клиентского приложения/браузера, компонентов тем и плагинов, или есть и другие компоненты.

У меня есть вопросы, например: «Стандартное сообщество Discourse не стоит за платным доступом или другими механизмами монетизации; можно ли их добавить?» Данные хранятся в системе с определённой степенью триады КЦД — конфиденциальность, целостность и доступность. Можно ли ужесточить её до стандартов, требуемых для стандартов интероперабельности в сфере здравоохранения по обе стороны Атлантики?

Последнее требование переводит разговор в сторону этики, и я считаю, что обсуждение того, как программное обеспечение поддерживает правовые, моральные и культурные вопросы, соответствует тематике этого форума. Понимание архитектуры является необходимым условием для проектирования решений, как и определение философских принципов, которые формируют желательные, необходимые и нежелательные/неприемлемые/подлежащие осуждению функции, а также то, как должно осуществляться осуждение.

13

Отлично, вы начинаете понимать. Основная база данных тематик сгруппирована по категориям и организована с помощью тегов, например, здесь.

Существует два вида #theme:

  • Базовый — просто изменяет внешний вид Discourse.
  • Полная тема — изменяет внешний вид и поставляется в комплекте с некоторыми #theme-component для изменения функциональности с помощью компонентов.

Это изображение. Вызов бокового меню

Screenshots_2023-09-10-05-42-44
Screenshots_2023-09-10-05-42-44806×1651 122 KB

Внизу, где я выделил стрелкой, нажмите «Развернуть». У вас есть коллекция тем — от базовых до полных. Поэкспериментируйте, выберите одну и посмотрите, как изменится внешний вид и ощущения от Meta здесь.

Попробуйте несколько разных тем и исследуйте их. Я думаю, это поможет лучше понять, что могут делать темы с компонентами и без них.

Например, тема Air — это полная тема с предустановленными компонентами.

14

Спасибо.

Думаю, этот ответ показал мне, что темы загружаются на стороне сервера, а клиент при запуске запрашивает список доступных тем. Затем при каждом получении данных (или при инициализации сеанса?) для отображения передаётся идентификатор темы, который сервер использует для определения, какие элементы HTML будут отправлены клиенту для отображения.

Также вы упомянули, что приложение нужно пересобрать. Я предполагаю, что это процесс связывания (link edit)? По крайней мере, вы описываете статический механизм, а не динамически подключаемые библиотеки?

У меня всё ещё нет чёткого представления о том, что могут предоставить подключаемые сервисы и как тема будет взаимодействовать с системой, кроме как изменением моей иконки с круга на квадрат, что, кажется, произошло, когда я выбрал ту, которую вы назвали — Air?

16

В отличие от более старых платформ форумов (vBulletin, phpBB), Discourse — это не набор плоских серверных скриптов (php) и отдельной базы данных.

Discourse состоит из двух частей: бэкенда, работающего в Docker, и одностраничного JavaScript-приложения, которое предоставляется клиентскому устройству.

Любые изменения, требующие модификации бэкенда, влияют на контейнер Docker, что в самых простых установках требует небольшого времени простоя. Именно это имеют в виду, когда говорят о необходимости пересборки приложения. Файл конфигурации (документ YAML), управляющий сборкой контейнера, нужно отредактировать, а затем через SSH отправить команду на пересборку в launcher. Установка плагинов требует пересборки, тогда как простые изменения SMTP больше похожи на перезапуск.

Внедрение новых тем и компонентов тем — это по сути изменения фронтенда, выполняемые в рамках работающего веб-приложения. Они не приводят к простою, так как базовое приложение и база данных фактически остаются неизменными.

17

Спасибо, Стивен :slight_smile:

У меня есть некоторые пробелы в технических знаниях. Мой практический опыт восходит к эпохе до Docker! На самом деле я помню, когда обоснование Джеймсом Гослингом Java как легковесного языка было самой горячей публикацией месяца — в то время я работал с K&R C, переходил к Ingres, Oracle, занимался системным администрированием и был администратором баз данных.

Мне кажется, я улавливаю использование терминов «фронтенд» и «бэкенд» как процессов, работающих на сервере, а не в контексте «клиент-сервер». Так ли это?

Имеем ли мы дело с кооперирующимися процессами, использующими общую память или каналы (pipes), или чем-то подобным, работающими на сервере, а затем потоком сообщений, инкапсулированным в TCP, который отправляет данные на IP-адрес, где установлено клиентское ПО?

Кто-нибудь рисовал блок-схему этой архитектуры?

18

Кажется, это уже точно ушло от #community :slight_smile: Давайте перенесём это в Development, так как речь идёт больше о технических аспектах.

20

Эта тема, похоже, объединяет две идеи:

  1. «Мне будет полезен общий обзор/схема для проектирования моего экземпляра Discourse».
  2. «Я пытаюсь сравнить функциональность Discourse с моими требованиями, но не могу найти определённую информацию».

Первый пункт, касающийся архитектуры, уже обсуждался, но, к сожалению, до сих пор отсутствует общая схема. Надеюсь, кто-то с лучшим пониманием сможет нарисовать что-то для нас здесь с помощью mermaid, однако я, по крайней мере, (надеюсь) смогу дать немного рекомендаций по вашим первоначальным требованиям.

Может ли Discourse соответствовать требованиям и стандартам информационной безопасности в медицине, государственных органах и автомобильной промышленности?

Вам нужно быть более конкретным в отношении того, что именно представляют собой эти требования. Однако, учитывая, что медицина и автомобильная промышленность не так уж далеко друг от друга, я могу поделиться своим опытом в надежде, что это поможет. Для контекста: я управляю инстансом в рамках инициативы Innersource для крупного автомобильного поставщика в Германии. Это было юридическим головной болью, но достижимо при наивном уровне настойчивости, идиотском уровне отказоустойчивости и невероятно полезной и терпеливой юридической команде. Серьёзно, будьте максимально вежливы со своей юридической командой :laughing:

Самые важные вопросы, на которые вам нужно ответить:

  1. Кто получает доступ к информации?
    • Публика?
    • Сотрудники?
    • Смесь сотрудников и публики?
  2. Какая информация будет размещена на платформе?
    • Только публичная?
    • Смесь публичной и внутренней?
    • Конфиденциальная? — обратите внимание: как только вы планируете разместить что-то конфиденциальное на платформе, всё значительно усложняется.
  3. Где это будет размещено?
    • На собственных серверах (on-site)
    • У Discourse или другого хостинг-провайдера

В нашем случае мы работали только с внутренними пользователями (сотрудниками), размещали только внутреннюю информацию (например, информацию компании, не являющуюся конфиденциальной), и изначально размещались самостоятельно, но затем перешли на хостинг от Discourse.

Что касается хостинга с Discourse, наш отдел информационной безопасности не увидел существенных проблем, когда мы приняли решение о миграции.

Мы также распространяем эту информацию по нескольким странам: Китай, Индия, Германия, Румыния, США, Франция и т. д. Китай оказался немного проблемным, но команда Discourse проделала отличную работу, чтобы помочь нам преодолеть проблемы с CDN, с которыми мы столкнулись.

Обратите внимание: вопрос номер 3 «Где это будет размещено?» отвечает на большинство ваших вопросов о защите данных и безопасности.

Вход в систему и авторизация

Для входа в систему вам, вероятно, стоит использовать SAML. Команда Discourse поможет вам настроить это, если вы являетесь корпоративным клиентом. Наш провайдер идентификации (IDP) доступен только тогда, когда вы находитесь за VPN компании, что добавляет дополнительный уровень безопасности (то есть вы даже не можете загрузить экран входа, если не находитесь в нашей сети).

SSH

Кроме того, стандартная установка обеспечивает шифрование SSH. Я не из ЦРУ, поэтому не знаю, нужно ли им что-то большее. :male_detective: предположительно

Интеграция Discourse с другими инструментами

Используйте API

Для интеграции ваш друг — API Discourse. Вы можете получать и устанавливать данные с помощью API-ключа и некоторого кода на Python.

Отличный набор примеров доступен здесь: Discourse REST API comprehensive examples

Анонимизация данных пользователей для соответствия GDPR

Что касается GDPR, вы можете извлечь данные с платформы и исключить информацию о пользователях в точке источника, запустив запрос в Data Explorer.

Это отличается от использования API Discourse, где JSON-ответ обычно включает полную информацию о сообщении, такую как:

  • Содержимое сообщения (обработанный HTML и исходный Markdown)
  • ID сообщения
  • ID темы, к которой оно относится
  • Имя пользователя автора
  • Номер сообщения в теме
  • Временные метки создания и последнего обновления сообщения
  • Количество лайков, ответов, цитат и т. д.

Как получить Rising Posts и привычный интерфейс?

Возможно, вы этого не видели, но вы можете объединить эту тему:

с чем-то вроде этого:

21

Согласно закону HIPAA в США, при наличии любых медицинских записей практикующие врачи могут передавать эти данные родственникам, друзьям или опекунам, а также любому другому лицу, выбранному пациентом, если последним подписана официальная форма разрешения на раскрытие информации. Такие формы обычно имеют срок действия, ограниченный несколькими месяцами или годами.

Простая схема этого процесса выглядит так: вся медицинская информация хранится в огромном запертом хранилище, которое никогда не может быть открыто в экстренных ситуациях, если только сотрудники экстренных служб не имеют подписанных пациентом документов.

Исключение: если пациент без сознания, особенно в долгосрочной коме или в состоянии, когда он не способен принимать решения, и/или судья официально признал его неспособным заботиться о своих делах, в этом случае может быть назначено другое лицо.

Оба этих сценария можно представить как ключ, который открывает хранилище, после чего часть медицинских данных перемещается во вторичное хранилище с ограниченным доступом только для конкретных лиц.

Это может быть группа людей, но в большинстве случаев, как я полагаю, каждый из них должен быть индивидуально указан для получения авторизации на доступ к медицинским данным.

https://www.cdc.gov/phlp/publications/topic/hipaa.html