在更大的 Rails 应用中作为一部分使用 Discourse？

开发
1

是否可以将 Discourse 作为更大的 Rails 应用的一个组件来使用？

我的目标：

  • 共享数据库：我希望我的 Rails 应用能够使用与 Discourse 相同的数据库。
  • 共享登录系统：如果我能利用 Discourse 的登录系统，并复用其会话 Cookie，让用户在应用的不同部分都能保持认证状态，那就太好了。
  • 为我的组件添加大量新的路由。
  • 额外目标：自定义 Discourse 的视图辅助方法，将已登录用户引导至这些额外的组件（这是否可以通过设置完成？或者是否有可复写的 Rails 辅助方法，用于自定义全站信息）？

我曾看到一篇关于使用 HAProxy 将 Discourse 置于代理之后并路由到域名下某个路径的文章。但这并不是我想要的，因为我希望避免在另一个应用中重复部署 Rails 框架（而且我也不确定在另一个应用中复用用户会话是否容易）。是否可以将 Discourse 作为更大 Rails 应用中的一个组件来使用？

2

我甚至不确定这是否可行，但即便可行，也不一定推荐这样做。

  1. 由于您的安装过于定制化，我们的社区将无法提供支持。
  2. 您需要负责合并 Discourse 的任何更新。考虑到我们向代码库提交的频率，根据您的修改内容，这可能会给您带来大量的工作量。

您其实已经可以通过 SSO（单点登录）在一定程度上实现这一功能。对于这类需求，采用 SSO 是更为推荐的方案。

3

太好了。我很高兴提前了解到这并不被推荐，这样我就省去了尝试后惨败的麻烦！

好的。听起来最好的方法是使用两个 Rails 应用（Discourse 和我的自定义应用）并通过反向代理进行部署。

经过考虑，保留两个数据库似乎是更好的选择，这样可以确保我的应用不会以 Discourse 作者从未设想过的不良方式更新 Discourse 数据库。

谢谢。

4

嗯，我会不那么悲观。你也可以说这可能是一个非常大的插件。

Custom Wizard 插件太大了，几乎像一个独立的应用（尤其是在前端）。

Discourse 中内置了许多可复用的通用功能，例如用户账户框架和功能、部署管道等等。

此外，在前端，你可以围绕 Discourse 灵活实现许多用例。例如，主题就是你的页面等等。

我认为关键在于细节。

这只是我的一点浅见。

5

没错——你可以构建一个大型插件来集成你的“应用”。根据你想深入的程度，这里有很多可能性！

6

拥有独立应用的好处——我们可以在此为您提供更好的支持，且 Discourse 的任何更新都不会破坏您应用端的功能。

将站点作为“大型 Discourse 插件”的好处——您可以获得 Discourse 中提供的所有功能、辅助工具（包括所有用户管理功能），这些价值不容小觑。

这取决于您正在构建的内容，听起来很酷——不过我认为 @justin 想提醒您注意由此可能带来的维护负担。如果您直接在 Discourse 上进行扩展开发，我们无法为您提供全面支持，而且我们所有的内部辅助工具和架构方案都“可能随时变更”（Subject To Change™），因此这样做可能得不偿失。（当然，这也取决于您具体在构建什么！在某些情况下，它完全可能物超所值 ;)）

8

是的，这非常正确。编写能够适应核心变更的稳健插件需要经验。你需要不断调整应用的某些部分，以跟上 Discourse 的更新。但这完全是可以实现的。

9

我简单看了一下插件。我更喜欢使用不同于 Ember 的 JS 框架（我是 Svelte 的粉丝），而且有点担心这会在 Discourse 的 Rails 应用中增加一层接口，让我这个不熟悉 Discourse 的人更难排查问题。我倾向于将其作为一个独立应用来开发。我对 Rails 相当熟悉（也很擅长代理 Rails 应用），但还不了解 Discourse，觉得走独立应用的路线会少很多障碍。