是否有2个应用程序查询1数据库

Question

首先，我会为我糟糕的英语道歉......

我正在研究一种从本地数据库提供数据的API。 数据库中的数据由另一个应用程序（称为CMS）管理。 API需要在不使用CMS（客户希望）的情况下运行。

有两种方法可以管理API数据库中的数据。

第一种方式是CMS从“API后端”调用其他API来更新API数据库。相同的“API后端”通过API API网关将数据从数据库提供给API网关，这使得整个事物可以扩展并管理API密钥等等。

第二种方式是CMS直接在API数据库中管理数据，“API后端”通过API网关的休息连接提供数据库中的数据......“同一故事”< / p>

在这种情况下，“API后端”只读取数据库中的数据，因此2个应用程序尝试在同一记录上写入是不可能的。

现在我的问题： 这些方法中的一种或两种是解决我的“问题”的正确（通常）方法吗？ 我选择了第一个解决方案，第二个是我的同事之一。

我说从另一个应用程序查询数据库并不简洁。他说，在第二种情况下，你需要编程1 API少（与CMS通信的那个），这样可以节省时间。

在我们的情况下，时间不是问题，但是在一个比我们需要更少时间的方式做到这一点时，它是完整的。

Answer 1

您描述的架构通常称为＆＃34; content as a service＆＃34;或者＆＃34;无头CMS＆＃34;。它已经成为一种流行的设计 - 它允许您在网站，移动应用程序，信息亭等中使用您的内容，并且 - 理论上 - 将您的网站与CMS供应商分离。

当你说＆＃34; CMS＆＃34;时，我假设你自己构建这个，而不是使用现成的解决方案。如果是这样的话，我会考虑先看看现成的;它几乎肯定会比你自己写的更便宜，更快捷，更好。

但是，如果你自己构建这个，你的问题归结为＆＃34;面向服务＆＃34;与＃34;数据导向＆＃34;设计。通常，将这两种模式结合起来是有风险的 - 它使应用程序更复杂，因此更容易出错。对于小型应用程序而言，这可能不是什么大问题，但对于大型，长期或关键业务应用程序而言，这是一件坏事。

通过CMS的基本任务进行思考可能会有所帮助 - 编辑现有文章。

在面向服务的设计中，CMS代码类似于：

article = articleService.get(id)
application.render(article)
onSave(article)
  articleService.put(article)

在混合设计中，它可能看起来像....

article = articleService.get(id)
application.render(article)
onSave(article)
  db.updateArticleHeader(date, user, article.metaData.title, article.metaData.byLine)
 forEach(article.Header.keywords)
   if not (db.getArticleKeywords.contains (keyword))
     db.addArticleKeyword(keyword)
 next
 db.updateArticleBody(article.body)

（当然，这会遗漏所有数据库逻辑）。 CMS应用程序中还有更多代码，还有更多逻辑。

现在想象一下当您向文章添加另一个属性时会发生什么 - 您必须更新CMS中的数据库层，渲染层和业务逻辑层。

如果您有一种面向服务的方法，只需运气一点，您只需要更改服务层。

＆＃34;纯＆＃34;通常不是评估软件的有用方法。使用既定的非功能性要求会更好：

• 性能：混合模型可能更快，因为它删除了API 层。
• 开发时间：混合模型可能更快简单 解决方案;对于复杂的应用程序，它的构建速度可能更快 API层和集中逻辑。
• 可维护性和可扩展性：面向服务的方法通常（更好）适用于除了琐碎的应用程序以外的任何其他方法

Answer 2

实际上，这两种情况都非常接近。无论您是直接写入数据库还是通过其他层，都可以归结为它。其余的是相同的。

所以，恕我直言，我遵循KISS原则并选择最直接的解决方案。 ......它不一定是那个或那个。它可能依赖于您的技术堆栈和当前代码。

除此之外，两种选择之间的两个关键差异是......

直接数据库访问

• 它快速且高度可定制。您可以轻松优化您的查询。非常方便大数据。

通过REST API进行访问

• 在这里，您有另一个序列化/网络/反序列化的传递。这很可能是可忽略不计的开销，但如果你用请求轰炸它就值得一提。
• 如果您必须更改所写的数据或方式，则可能需要调整两个位置：CMS 和后端API
• 通过Backend API提供了一种简单的方法来应用通用的东西（日志记录，统计，验证，监控......）......以备你需要的时候。否则，忘记它，YAGNI
• ...如果其他服务也需要这个REST API，它可能很有用......否则，YAGNI

基本上，在你的情况下我会以任何简单的方式去做。

无论如何，这不是一件大事。您可以在界面后面对其进行抽象，以便您可以随时交换它是通过REST API还是通过DB。它只是将一些代码从数据库访问层移植到后端API，反之亦然，只要它是相同的语言。