API 应该是我的 python 项目中的模块还是新项目？
Should an API be a module in my python project or a new project?
我们有一个 python 客户端与之交互的 Web 应用程序，该 Web 应用程序直接与数据库交互。我们现在需要开发一个 API，商家将使用它来获取 post 数据 from/in 我们在 JSON 中的数据库。我们应该将 API 构建为网络应用程序的一部分，这意味着每个请求都将通过我们的 python 网络应用程序然后与数据库交互，还是应该将其分开？
进一步的考虑包括可扩展性，以及未来我们可能想要开发移动应用程序或其他也需要与数据库通信的服务。因此，我们考虑了构建 API 作为与数据库交互的唯一点的可能性。
然而，我们正在深入开发 flask web 应用程序，改变它意味着我们的日程安排会大大延迟，我们只是想权衡这两种解决方案的优缺点。
这两个方案总结了我们正在考虑的选项：
选项 1：
选项 2：
如您所说，两种选择各有利弊。
选项 1 给你 Separation of Concerns。与数据库交互的逻辑被抽象为单个服务。更改您使用的数据库类型或您使用的模式只需要更改单个服务的代码。例如，假设您的平台已经扩展，您现在希望缓存对数据库的调用。如果您有 API、Web 应用程序和移动应用程序都直接与数据库通信，则必须更新它们以利用缓存。这些更改可能还必须经过编排才能同时部署。实际上，这将涉及停机时间：通常您会看到它被称为 'scheduled maintenance'。
但是，选项 1 打破了 Single Responsibility Principle。一个服务应该只做一件事并且把它做好。在选项 1 中，服务负责作为数据库的接口并为 Web 应用程序呈现 HTML。对 Web 应用程序的更改要求您重新部署 API 的服务，即使两者未连接。
方案二的优缺点大多与方案一的优缺点正好相反。多个服务共享一个数据库会导致数据不一致，紧耦合（尤其是在部署时），调试困难比较难。
一种常见的设计模式（我推荐）是对选项 1 的轻微修改。API 位于数据库前面。这是与数据库交互的唯一服务。此设置应该会提高您的可扩展性。很容易部署重复的 APIs，然后在它们之间负载平衡请求。此外，缓存数据库查找或完全改变数据库技术是一项（相对）简单的任务。您的 Web 应用程序或您将来开发的任何其他服务与 API 而不是数据库进行交互。在这里，您可以享受单一职责的好处。值得注意的是，通过这种设计，对 Web 应用程序的每个请求都必须通过两个服务。然而，这种设计的好处可以说比延迟几毫秒更重要。
最后一件事：这么早考虑可扩展性的荣誉。如果你的日程被推迟，你现在可能会受到打击，但我认为从长远来看你会过得更好。
我们有一个 python 客户端与之交互的 Web 应用程序，该 Web 应用程序直接与数据库交互。我们现在需要开发一个 API，商家将使用它来获取 post 数据 from/in 我们在 JSON 中的数据库。我们应该将 API 构建为网络应用程序的一部分，这意味着每个请求都将通过我们的 python 网络应用程序然后与数据库交互，还是应该将其分开？ 进一步的考虑包括可扩展性，以及未来我们可能想要开发移动应用程序或其他也需要与数据库通信的服务。因此，我们考虑了构建 API 作为与数据库交互的唯一点的可能性。 然而，我们正在深入开发 flask web 应用程序，改变它意味着我们的日程安排会大大延迟，我们只是想权衡这两种解决方案的优缺点。 这两个方案总结了我们正在考虑的选项：
选项 1：
选项 2：
如您所说，两种选择各有利弊。
选项 1 给你 Separation of Concerns。与数据库交互的逻辑被抽象为单个服务。更改您使用的数据库类型或您使用的模式只需要更改单个服务的代码。例如，假设您的平台已经扩展，您现在希望缓存对数据库的调用。如果您有 API、Web 应用程序和移动应用程序都直接与数据库通信，则必须更新它们以利用缓存。这些更改可能还必须经过编排才能同时部署。实际上，这将涉及停机时间：通常您会看到它被称为 'scheduled maintenance'。 但是，选项 1 打破了 Single Responsibility Principle。一个服务应该只做一件事并且把它做好。在选项 1 中，服务负责作为数据库的接口并为 Web 应用程序呈现 HTML。对 Web 应用程序的更改要求您重新部署 API 的服务，即使两者未连接。
方案二的优缺点大多与方案一的优缺点正好相反。多个服务共享一个数据库会导致数据不一致，紧耦合（尤其是在部署时），调试困难比较难。
一种常见的设计模式（我推荐）是对选项 1 的轻微修改。API 位于数据库前面。这是与数据库交互的唯一服务。此设置应该会提高您的可扩展性。很容易部署重复的 APIs，然后在它们之间负载平衡请求。此外，缓存数据库查找或完全改变数据库技术是一项（相对）简单的任务。您的 Web 应用程序或您将来开发的任何其他服务与 API 而不是数据库进行交互。在这里，您可以享受单一职责的好处。值得注意的是，通过这种设计，对 Web 应用程序的每个请求都必须通过两个服务。然而，这种设计的好处可以说比延迟几毫秒更重要。
最后一件事：这么早考虑可扩展性的荣誉。如果你的日程被推迟，你现在可能会受到打击，但我认为从长远来看你会过得更好。