Discourse を大きな Rails アプリケーションのコンポーネントとして使用することは可能でしょうか?
私の目標は以下の通りです:
- データベースの共有:私の Rails アプリが Discourse と同じデータベースを使用できれば理想的です。
- ログインの共有:Discourse のログインシステムを利用し、セッションクッキーを再利用して、アプリ内の異なる場所でユーザーを認証できれば素晴らしいです。
- コンポーネントに多数の新しいルートを追加する。
- ボーナス:ログインユーザーをこれらの追加コンポーネントへ誘導する Discourse のビューヘルパーをカスタマイズする(これは設定だけで実現できるかもしれませんが、サイト全体の情報をカスタマイズするためにオーバーライド可能な Rails ヘルパーは存在するのでしょうか?)
HAProxy を使用して Discourse をプロキシの背後に置き、ドメイン上のパスにルーティングする方法についての投稿を目にしました。しかし、それは私の望むものではありません。別のアプリで Rails フレームワークを複製したくないですし、別のアプリでユーザーセッションを再利用する方法も確信が持てないためです。Discourse をより大きな Rails アプリケーションのコンポーネントとして使用することは可能でしょうか?
justin
(Justin DiRose)
2
実際に可能かどうかさえ確信はありませんが、仮に可能だとしても、必ずしも推奨される方法ではありません。
- インストールがカスタマイズされすぎているため、コミュニティによるサポートは提供できません。
- Discourse の変更点をマージする責任があなたに生じます。私たちがリポジトリにコミットするペースを考えると、変更内容によっては非常に多くの作業が必要になる可能性があります。
SSO を使用すれば、ある程度このように実装可能です。この種の用途には、より推奨されるアプローチです。
それは素晴らしいですね。事前にそれが推奨されていないと知れて、試して大失敗する手間が省けました!
わかりました。最適な方法は、リバースプロキシの背後に2つのRailsアプリ(Discourseとカスタムアプリ)を配置することのようです。
検討した結果、私のアプリがDiscourseのデータベースを、Discourseの開発者が意図しない方法で更新してしまうのを確実に防ぐため、ここでは2つのデータベースを維持する方が良さそうです。
ありがとうございます。
うーん、もう少し楽観的になってもいいかもしれませんね。これは非常に大規模なプラグインだと言えるでしょう。
Custom Wizard プラグインは非常に大きく、ほぼ独立したアプリケーションのようになっています(特にフロントエンド側では)。
Discourse には、ユーザーアカウントのフレームワークや機能、デプロイパイプラインなど、再利用できる汎用的な有用な機能が多数組み込まれています。
また、フロントエンド側では、トピックをページとして扱うなど、Discourse を様々なユースケースに合わせて柔軟に拡張することも可能です。
ここでの肝は細部にあると思います。
私の個人的な意見です。
justin
(Justin DiRose)
5
その通りです。「アプリ」を統合するために大規模なプラグインを構築することも可能です。どの程度深く統合するかによって、さまざまな選択肢があります!
別アプリを持つメリット - こちらでより良いサポートを提供できますし、Discourse の更新があなたのアプリ側に影響を与えることもありません。
サイトを「大規模な Discourse プラグイン」として構築するメリット - Discourse で利用可能なすべての機能やヘルパー(ユーザー管理機能など)をフル活用できます。これは軽視できません。
あなたが何を構築するかによりますが、@justin は、メンテナンスの負担について注意を促したいと考えています。Discourse に直接依存して構築する場合、完全なサポートを提供することはできません。また、内部のヘルパーやスキーマはすべて「変更される可能性があります (Subject To Change)」ため、手間に見合わない可能性もあります(もちろん、構築内容によります!手間に見合う可能性も十分にあります ;))。
その通りです。コアの変更に対して堅牢なプラグインを作成するには経験が必要です。Discourse の変化に合わせてアプリのいくつかの要素を進化させる必要がありますが、実現可能です。
プラグインを少し見てみました。Ember ではなく別の JS フレームワーク(私は Svelte ファンです)を使いたいと考えており、Discourse の Rails アプリ(私はまだ慣れていません)にレイヤーやインターフェースが追加され、トラブルシューティングがより複雑になるのではないかと少し懸念しています。そのため、これを別アプリとして維持する方向に傾いています。Rails はよく知っており(Rails アプリのプロキシ設定も得意ですが)、Discourse はまだ知らないため、この道を選べば障壁が少なくなるように感じています。