database - 有 2 个应用程序查询 1 个数据库是否整洁

Question

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

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

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

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

在第二种方式中，CMS 直接在 API 数据库中管理数据，“API 后端”通过与 API 网关的 rest 连接提供来自数据库的数据......“同一个故事”

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

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

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

在我们的情况下，时间不是问题，但如果以一种比我们需要的时间更少的方式来做这件事是很巧妙的。

Answer 1

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

当您说“CMS”时，我假设您是自己构建它，而不是使用现成的解决方案。如果是这样的话，我会考虑先看看现成的；它几乎肯定会比您自己编写的任何东西都更便宜、更快和更好。

但是，如果您自己构建它，您的问题归结为“面向服务”与“面向数据”的设计。一般来说，将这两种模式结合起来是有风险的——它会使应用程序更加复杂，因此更容易出错。对于小型应用程序，这可能不是什么大问题，但对于大型、长期或业务关键型应用程序，这是一件坏事。

考虑 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 中的 DB 层、呈现层和业务逻辑层。

如果您采用面向服务的方法，运气好的话，您只需更改服务层即可。

“整洁”通常不是评估软件的有用方法。最好使用既定的非功能性需求:

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