关于基于 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 方法：

SubmitEntry

GetEntry

SearchEntries

GetComments

SubmitComment

总体思路是您的服务完成/完成所有工作。字体端应用程序只是一个 GUI。使用 MVC，您的前端仍然可以有一个模型 - 它只会进行 API 调用而不是数据库调用。

至于使用什么语言，这真的取决于你。Go 是一种了不起的语言。它的社区发展迅速，但还很年轻。您可能无法找到本来可以在 Ruby 中使用的包。您可能最终不得不自己编写。话虽如此，Go 有很大的潜力，而且写起来很有趣！

个人经验：我工作的公司以前用的是PHP。一年前，我们决定需要做出改变，于是我们决定使用 Go。我们不得不自己编写一些库，但总体而言，这是令人惊叹的一年。我们现在只使用 Go（带有一点 C/C++）。