关于基于 API 的应用程序开发的困惑

Question

传统上，我使用 Ruby on Rails 构建应用程序，很少提取服务。我现在正在转向更易于管理和高性能的东西（SOA w/ API）。

我感到困惑的是，如果我用 Go 之类的东西构建 API 服务器，我究竟会失去什么。假设我有一个文章模型，通过系统的旅程会是什么样子？我的意思是在 ORM、控制器、API 等方面。

如果我在 Go 中有一个 API，ORM 会在 API 的级别上，还是我仍然可以使用 Rails（它会与 API 对话）？那么控制器呢？我迷失了这个堆栈是否有意义：

• 作为 API 服务器

• Rails 作为应用服务器

我担心的是，如果我采用这种方法，我是否会丢失很多 Rails 附带的功能，比如迁移。

Answer 1

对于 SOA，我不会真的说这一定是 Go 或 Ruby/Rails 特定的。如果你只是单独使用 Ruby 或 Go 也是一样。什么它归结为是如何应用程序的架构。您可以仅使用 Ruby 或 Go 来实现 SOA。面向服务的架构有很多好处。明确的职责分离不同的团队可以处理不同的组件代码方面的简化应用程序架构可以降低开发和管理成本配置灵活性有针对性的绩效监控简化/渐进式软件更新固有服务文档（godoc 从源代码生成）有针对性的单元测试（服务是否有效？）更好的可扩展性您可能可以在该列表中添加更多好处。要克服的最大障碍是最初的计划，尤其是第一次。你把事情分解到什么程度？哪些东西应该分开？如果您没有找到正确的平衡点，您最终可能会失去收益。至于如何设计 SOA 架构，这真的取决于。如果我正在构建一个包含文章和评论的博客服务，您可以使用以下 API 方法：SubmitEntryGetEntrySearchEntriesGetCommentsSubmitComment总体思路是您的服务完成/完成所有工作。字体端应用程序只是一个 GUI。使用 MVC，您的前端仍然可以有一个模型 - 它只会进行 API 调用而不是数据库调用。至于使用什么语言，这真的取决于你。Go 是一种了不起的语言。它的社区发展迅速，但还很年轻。您可能无法找到本来可以在 Ruby 中使用的包。您可能最终不得不自己编写。话虽如此，Go 有很大的潜力，而且写起来很有趣！个人经验：我工作的公司以前用的是PHP。一年前，我们决定需要做出改变，于是我们决定使用 Go。我们不得不自己编写一些库，但总体而言，这是令人惊叹的一年。我们现在只使用 Go（带有一点 C/C++）。