ruby-on-rails - 使用 Rails/Sinatra 的只读网络应用程序

Question

我正在使用 Rails 开发一个管理网络应用程序。由于各种并不真正相关的实现细节，支持此应用程序的数据库将具有支持另一个单独网站所需的所有内容。似乎有两个明显的选择:

1. 构建一个网络应用程序，以某种方式以只读方式从同一个数据库读取数据。
2. 向原始应用添加 RESTful API，并构建第二个网站，使其从 API 获取内容。

我的问题是:这两种选择是否可行？如果是这样，他们中的哪一个似乎是更好的选择？ Rails、Sinatra 或任何其他基于 Rack 的 Web 框架是否特别适合此类项目？ (我倾向于 Sinatra，因为它看起来比 Rails 更轻巧，而且我认为我的 Rails 经验会很好地延续到它身上。)

谢谢!

Answer 1

这两种方法都是可行的，我过去都使用过，但我会选择 API 方法。

快速免责声明:尚不清楚的一件事是这些应用程序在功能上有何不同。例如，我可以想象旧的是一个 CRUD 应用程序，用于处理个人记录，而新的是一个报告应用程序，它可以进行大型复杂的聚合查询。这使得共享数据库(可能)更具吸引力，因为您访问数据的方式的重叠非常小。我在下面假设情况不是。

无论如何，API 方法。先说不好的:

• 另一个依赖项(旧应用)。当它崩溃时，它会关闭两个应用程序。
• 多了一个获取数据的跃点，因此延迟更高。
• 使用现有代码不如编写新代码有趣。就是这样。

但另一方面，好处是:

• 对架构更改的弹性要大得多。您的“旧”应用程序的 API 可以进行测试，并且您可以随心所欲地处理数据库(在旧应用程序的上下文中)，并让您的 API 符合其规范。您的新应用程序不会知道其中的区别，这很好。抽象FTW。这是“多一个依赖”硬币的反面。

• 观点相同，但角度不同:在我们共享数据库的方法中，您的架构 + 所有 SQL 实际上就是您的 API，它有两个客户端，旧应用程序和新应用程序。除非您的两个应用程序使用相同的数据做非常不同的事情，否则那不可能是最好的 API。定义太模糊了。

• 数据库管理员/工具更好。假设您搞砸了一些查询并管理了您的数据库。它是哪个应用程序？这些查询来自哪里？基本上，可以与您的数据库交互的东西越少越好。相关:在一个地方而不是两个地方优化您的读取查询。

• 如果您在现有应用中使用 RESTful 路由执行非 API 操作，我猜您的 API 需求将与现有 Controller 代码有很大重叠。这可能只是将数据转换为 JSON 而不是将其传递给 View 的问题。 Rails 使得使用操作来响应 API 和用户驱动的请求变得非常容易。因此，如果适用，那将是一个巨大的 DRY 胜利。

• 如果您发现您确实希望在您的新应用程序中具有一些可写性，会发生什么？或者至少访问您的旧应用程序不关心的某些字段(也许您使用脚本添加了它)？在共享数据库方法中，这很糟糕。对于另一个，只需稍微扩展 API 即可。

基本上，我选择共享数据库方法的唯一方法是我讨厌旧代码并想重新开始。这是可以理解的(我也确实这样做了)，但这不是架构上最合理的选择。

要考虑的第三个选项是在两个应用程序之间共享代码。例如，您可以完善模型代码。现在您的 API 实际上是一些知道如何与您的数据库对话的 Ruby 类。更进一步，您可以编写一个 Sinatra 应用程序并将其安装在现有 Rails 应用程序中并重用它的大部分。然后只需制定路由，使它们在外界看来就像独立的应用程序。这是否实用显然取决于您的具体情况。

在具体技术上，Sinatra和Rails都是不错的选择。我倾向于将 Rails 用于较大的项目，而将 Sinatra 用于较小的项目，但那只是我。做感觉良好的事情。