理解“后端”

Question

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

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

Answer 1

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

一般来说，--“前端”是用户会看到的东西。为了实现这一点，必须在用户设备上“存储和执行”该代码。我非常肯定，这意味着(有经验的)用户将能够查看前端的代码，并可能能够理解它的工作原理。(稍后我将更多地解释为什么这是相关的。)

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

哪里去了？

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

• 基于用户偏好(例如基于浏览器、移动应用程序、命令行接口，.)，单个后端可以有许多不同的前端。
  • 它们可以有不同的发布周期和更新机制，因此对后端的更改可能需要保持向后的
  • 。

• 出于安全、操作或数据一致性的原因，您可能需要在后端实现错误/无效输入的处理，特别是当(某种)通信协议发生更改时。特别是因为提供前端也意味着可能知道如何调用后端，所以也有可能以不同的方式调用它(无论是故意调用还是通过前端和后端之间的accident).
• Since操作都很可能是异步的)，某些错误处理(比如连接问题)只能在前端side.
• Authentication和授权/秘密管理中处理:如果后端只是数据库的API，它需要知道正确的凭据，因此，它们需要以某种方式交付给用户，并且可以被检查(并且可能是"mis"used)
• same的业务逻辑:可能有知识产权或战略原因不将其交付给用户或潜在的竞争公司。)

当然，您需要考虑有多少资源可用于实现满足您需要的解决方案。