了解“后端”[关闭]

Question

到底什么是后端代码？它只是 API吗？后端是否有业务逻辑？

例如，如果我有一个时间表应用程序并且用户输入他们当天的时间，那么将这些信息添加到数据库中的逻辑是否都在前端？而后端只是为了公开一个 API 来向数据库添加/更新信息？对于这个简单的时间表应用程序，一般来说，前端与后端分别是什么？

Answer 1

这是一个非常广泛的问题/主题，但我将尝试解释我对这些术语的看法以及如何决定将内容放在哪里：

一般来说，“前端”是用户将看到的。为了使这成为可能，该代码必须在用户设备上“存储和执行”。我很确定这意味着（有经验的）用户将能够查看前端的代码，并且可能能够理解它是如何工作的。 （我稍后会详细解释为什么这是相关的。）

另一端的“后端”通常作为某人提供的“原样”服务提供，可通过许多可用通信协议中的一个或多个及其接口通常以某种方式记录，即使它不是公开的。现在最突出的例子是 REST API 和 Graphql API。 正如您已经提到的，集中状态管理（例如存储数据）可能是其中的重要部分（但并非必须如此）。 当对后端“进行调用”时，一些代码会在某个服务器上执行，并且响应（如果有）是前端或用户了解的唯一新信息。

什么去哪儿了？

要决定代码的哪一部分放在哪里，需要考虑很多方面。没有灵丹妙药：我确信可以找到所有可能组合的示例。

• 根据用户偏好（例如，基于浏览器、移动应用程序、命令行界面等），单个后端可以有许多不同的前端。
  • 它们可以有不同的发布周期和更新机制，因此对后端的更改可能需要保持向后兼容。
• 出于安全、操作或数据一致性的原因，您可能需要在后端实现对错误/无效输入的处理，尤其是在（种类）通信协议发生变化时。尤其是因为提供前端还意味着可以知道如何调用后端，因此也可以以不同的方式调用它（无论是有意还是无意）。
• 由于前端和后端之间的操作很可能是异步的，因此某些错误处理（如连接问题）只能在前端处理。
• 身份验证和授权/秘密管理：如果您的后端只是数据库的 API，它需要知道正确的凭据，因此需要以某种方式将它们传递给用户并且可以检查（并且可能“误用”）
• 业务逻辑也是如此：可能有知识产权或战略原因不将其交付给用户或潜在的竞争公司。

当然，您需要考虑有多少资源可用于实施适合您需求的解决方案。