Возможно ли использовать Discourse как один из компонентов более крупного приложения на Rails?
Мои цели:
Общий доступ к базе данных. Я бы хотел, чтобы мое приложение на Rails использовало ту же базу данных, что и Discourse.
Общий вход в систему: было бы отлично, если бы я мог использовать систему входа Discourse и повторно использовать cookie сессии для аутентификации пользователей в разных частях моего приложения.
Добавить множество новых маршрутов для моих компонентов.
Бонус: настроить вспомогательные методы просмотра Discourse, которые перенаправляют авторизованных пользователей на эти дополнительные компоненты (возможно, это можно сделать исключительно через настройки, но интересно, есть ли переопределяемые вспомогательные методы Rails, которые можно использовать для настройки информации на уровне всего сайта)?
Я видел пост об использовании HAProxy для размещения Discourse за прокси-сервером и маршрутизации на путь в домене. Это не то, что мне нужно, потому что я бы хотел избежать дублирования фреймворка Rails в другом приложении (и не уверен, насколько легко можно повторно использовать сессию пользователя в другом приложении). Возможно ли использовать Discourse как компонент в более крупном приложении на Rails?
Я даже не уверен, что это вообще возможно, но даже если и возможно, это не обязательно хорошая идея.
Ваша установка никогда не будет поддерживаться нашим сообществом, так как она будет слишком кастомизированной.
Вам придётся самостоятельно сливать любые изменения в Discourse. Учитывая темп наших коммитов в репозиторий, это может означать огромный объём работы для вас, в зависимости от того, что вы измените.
Вы уже можете частично реализовать это с помощью SSO. Это более рекомендуемый подход для таких задач.
Отлично. Я рад, что заранее узнал, что это не рекомендуется, — это сэкономит мне время на попытки и неизбежный провал!
Хорошо. Похоже, лучший вариант — использовать два приложения на Rails (Discourse и моё собственное) за обратным прокси.
После раздумий кажется, что использование двух отдельных баз данных здесь — более разумное решение, чтобы гарантировать, что моё приложение не внесёт в базу данных Discourse изменения, которые авторы Discourse никогда не планировали.
Хм, я был бы менее пессимистичен. Можно также сказать, что это может быть очень большой плагин.
Плагин Custom Wizard настолько велик, что это почти отдельное приложение (особенно на фронтенде).
В Discourse уже написано много полезных универсальных вещей, которые можно переиспользовать, например, фреймворк учётных записей пользователей и его функциональность, конвейер развёртывания и т. д.
Кроме того, на фронтенде можно адаптировать множество вариантов использования под Discourse. Темы — это ваши страницы и так далее.
Верно — можно создать большой плагин для интеграции вашего «приложения». Здесь множество возможностей в зависимости от того, насколько глубоко вы хотите погрузиться!
Преимущества наличия отдельного приложения — мы сможем лучше поддерживать вас здесь, и любые обновления Discourse не сломают вашу часть приложения.
Преимущества того, чтобы сайт был «большим плагином Discourse» — вы получаете все возможности и вспомогательные инструменты, доступные в Discourse (включая все функции управления пользователями), что нельзя недооценивать.
Это было бы круто, в зависимости от того, что вы создаете. Я думаю, что @justin хочет предупредить вас о потенциальных накладных расходах на поддержку. Мы не сможем полностью поддерживать вас, если вы напрямую надстраиваете поверх Discourse, и все наши внутренние вспомогательные средства и схемы могут измениться (Subject To Change™), поэтому это может оказаться больше проблем, чем того стоит. (Конечно, в зависимости от того, что вы создаете! Это также может легко стоить затраченных усилий ;))
Да, это совершенно верно. Написание плагинов, устойчивых к изменениям ядра, требует опыта. Вам придется адаптировать некоторые элементы приложения, чтобы не отставать от изменений в Discourse. Но это вполне осуществимо.
Я бегло ознакомился с плагинами. Я предпочитаю использовать JS-фреймворк, отличный от Ember (я фанат Svelte), и немного обеспокоен тем, что это добавит слой/интерфейс к Rails-приложению Discourse (с которым я не знаком), что усложнит для меня устранение неполадок. Я склоняюсь к тому, чтобы оставить это как отдельное приложение. Я неплохо знаю Rails (и проксирование Rails-приложений), но пока не знаком с Discourse, и чувствую, что у меня будет меньше препятствий, если я выберу этот путь.