# 在更大的 Rails 应用中作为一部分使用 Discourse？
**URL:** https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312
**Category:** Development
**Created:** [2020年六月19日 05:03 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312 "2020-06-19T05:03:28Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@Chris\_Dawson](https://meta.discourse.org/u/Chris_Dawson)
#### Post date: [2020年六月19日 05:03 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/1 "2020-06-19T05:03:28Z")
是否可以将 Discourse 作为更大的 Rails 应用的一个组件来使用？
我的目标：
- 共享数据库：我希望我的 Rails 应用能够使用与 Discourse 相同的数据库。
- 共享登录系统：如果我能利用 Discourse 的登录系统，并复用其会话 Cookie，让用户在应用的不同部分都能保持认证状态，那就太好了。
- 为我的组件添加大量新的路由。
- 额外目标：自定义 Discourse 的视图辅助方法，将已登录用户引导至这些额外的组件（这是否可以通过设置完成？或者是否有可复写的 Rails 辅助方法，用于自定义全站信息）？
我曾看到一篇关于使用 HAProxy 将 Discourse 置于代理之后并路由到域名下某个路径的文章。但这并不是我想要的，因为我希望避免在另一个应用中重复部署 Rails 框架（而且我也不确定在另一个应用中复用用户会话是否容易）。是否可以将 Discourse 作为更大 Rails 应用中的一个组件来使用？
---
### Author:  [@justin](https://meta.discourse.org/u/justin)
#### Post date: [2020年六月19日 05:07 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/2 "2020-06-19T05:07:47Z")
> [@Chris\_Dawson](#):
>
> 能否将 Discourse 作为更大的 Rails 应用的一个组件来使用？
我甚至不确定这是否可行，但即便可行，也不一定推荐这样做。
1. 由于您的安装过于定制化，我们的社区将无法提供支持。
2. 您需要负责合并 Discourse 的任何更新。考虑到我们向代码库提交的频率，根据您的修改内容，这可能会给您带来_大量_的工作量。
> [@Chris\_Dawson](#):
>
> 共享登录：意思是，如果我能使用 Discourse 的登录系统，并复用会话 Cookie，让用户在我应用的不同位置保持认证状态，那就太好了。
您其实已经可以通过 SSO（单点登录）在一定程度上实现这一功能。对于这类需求，采用 SSO 是更为推荐的方案。
---
### Author:  [@Chris\_Dawson](https://meta.discourse.org/u/Chris_Dawson)
#### Post date: [2020年六月19日 05:10 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/3 "2020-06-19T05:10:29Z")
太好了。我很高兴提前了解到这并不被推荐，这样我就省去了尝试后惨败的麻烦！
好的。听起来最好的方法是使用两个 Rails 应用（Discourse 和我的自定义应用）并通过反向代理进行部署。
经过考虑，保留两个数据库似乎是更好的选择，这样可以确保我的应用不会以 Discourse 作者从未设想过的不良方式更新 Discourse 数据库。
谢谢。
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2020年六月19日 05:24 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/4 "2020-06-19T05:24:05Z")
嗯，我会不那么悲观。你也可以说这可能是一个非常大的插件。
Custom Wizard 插件太大了，几乎像一个独立的应用（尤其是在前端）。
Discourse 中内置了许多可复用的通用功能，例如用户账户框架和功能、部署管道等等。
此外，在前端，你可以围绕 Discourse 灵活实现许多用例。例如，主题就是你的页面等等。
我认为关键在于细节。
这只是我的一点浅见。
---
### Author:  [@justin](https://meta.discourse.org/u/justin)
#### Post date: [2020年六月19日 05:28 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/5 "2020-06-19T05:28:09Z")
> [@merefield](#):
>
> 你也可以说这可能是一个非常大的插件。
没错——你可以构建一个大型插件来集成你的“应用”。根据你想深入的程度，这里有很多可能性！
---
### Author:  [@featheredtoast](https://meta.discourse.org/u/featheredtoast)
#### Post date: [2020年六月19日 05:33 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/6 "2020-06-19T05:33:24Z")
拥有独立应用的好处——我们可以在此为您提供更好的支持，且 Discourse 的任何更新都不会破坏您应用端的功能。
将站点作为“大型 Discourse 插件”的好处——您可以获得 Discourse 中提供的所有功能、辅助工具（包括所有用户管理功能），这些价值不容小觑。
这取决于您正在构建的内容，听起来很酷——不过我认为 @justin 想提醒您注意由此可能带来的维护负担。如果您直接在 Discourse 上进行扩展开发，我们无法为您提供全面支持，而且我们所有的内部辅助工具和架构方案都“可能随时变更”（Subject To Change™），因此这样做_可能_得不偿失。（当然，这也取决于您具体在构建什么！在某些情况下，它完全可能物超所值 ;)）
---
### Author:  [@merefield](https://meta.discourse.org/u/merefield)
#### Post date: [2020年六月19日 05:35 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/8 "2020-06-19T05:35:25Z")
是的，这非常正确。编写能够适应核心变更的稳健插件需要经验。你需要不断调整应用的某些部分，以跟上 Discourse 的更新。但这完全是可以实现的。
---
### Author:  [@Chris\_Dawson](https://meta.discourse.org/u/Chris_Dawson)
#### Post date: [2020年六月19日 05:37 UTC](https://meta.discourse.org/t/using-discourse-as-one-part-of-a-larger-rails-app/155312/9 "2020-06-19T05:37:13Z")
我简单看了一下插件。我更喜欢使用不同于 Ember 的 JS 框架（我是 Svelte 的粉丝），而且有点担心这会在 Discourse 的 Rails 应用中增加一层接口，让我这个不熟悉 Discourse 的人更难排查问题。我倾向于将其作为一个独立应用来开发。我对 Rails 相当熟悉（也很擅长代理 Rails 应用），但还不了解 Discourse，觉得走独立应用的路线会少很多障碍。