2

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

  1. 构建一个 Web 应用程序，以某种方式以只读方式从同一数据库中读取数据。
  2. 将 RESTful API 添加到原始应用程序并构建第二个站点，以便它从 API 获取其内容。

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

谢谢！

4

1 回答 1

3

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

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

无论如何，API方法。首先，坏处：

  • 另一个依赖项（旧应用程序）。当它中断时，它会关闭两个应用程序。
  • 多一跳来获取数据，因此延迟更高。
  • 使用现有代码不如编写新代码有趣。只是。

但另一方面，好的：

  • 对架构更改更具弹性。您的“旧”应用程序的 API 可以进行测试，您可以随心所欲地使用数据库（在旧应用程序的上下文中），并保持您的 API 符合其规范。您的新应用程序不会知道其中的区别，这很好。抽象 FTW。这是“另一个依赖”硬币的反面。

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

  • 数据库管理员/仪器更好。假设您弄乱了一些查询并软管您的数据库。是哪个应用程序？这些查询来自哪里？基本上，可以与数据库交互的东西越少越好。相关：在一处优化您的读取查询，而不是两处。

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

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

基本上，我选择共享数据库方法的唯一方法是我讨厌旧代码并想重新开始。这是可以理解的（我已经做到了），但这不是架构上最合理的选择。

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

在具体技术方面，Sinatra 和 Rails 都是不错的选择。我倾向于 Rails 用于较大的项目，而 Sinatra 则用于较小的项目，但这只是我。做感觉好的事。

于 2012-07-17T06:19:02.910 回答