了解“后端”

如何解决了解“后端”

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

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

解决方法

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

通常，用户会看到“前端” 。为了使之成为可能，该代码必须在用户设备上“存储并执行”。我非常确定，这意味着（有经验的）用户将能够查看前端的代码，并且可能能够理解其工作方式。 （我将在后面解释为什么这很重要。）

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

去哪里？

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

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

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