前端工程师需要做的绝大多数工作都可以在不了解除API之外的任何其他信息的情况下完成。 如果您在前端的不同部分工作了足够长的时间，则可能会遇到需要一些后端知识的问题。 这是前端工程师应该了解的有关后端的简短主题列表。

要求费率

后端具有有限的资源，并且只能处理一定比率的请求。 通常，您无需在意-前端应该做它需要做的事情以创建出色的用户体验，并且后端可以优化和扩展。 尽管如此，发往后端的网络请求也不是免费的，并且它们也不都是同样昂贵的（就所使用的资源而言）。

您如何衡量通话的费用？ 一条经验法则是，写入的成本比读取的成本高，因此更改的数据越多，成本也就越高。 禁止这种情况的一个例子：假设您正在实施Google文档。 您希望用户退出后永远不会丢失他们的工作，因此可以节省很多时间。 您是否可以保存每个字符的插入和删除？

您的后端服务器可能无法处理它，否则处理它的基础结构成本将不必要地高。 仅在用户停止键入后才进行节流以达到预期效果的99％，而不会为此付出1％的巨额成本。

假设您要轮询后端以进行更改。 您想要最新版本的文档，那么您应该多久发出一次请求？ 读取比写入便宜很多，因此您可以比写入做更多的事情，但是仍然有一个限制。

限制取决于许多因素，例如任何给定时间的最大活动客户端数，后端基础结构和预算。 如果您认为所做的更改可能会接近极限，请与后端团队联系。 否则，您可能最终会使用DDOS创建自己的公司。

停机时间

对于某些用户，您应该期望并为每个后端请求在某些时候失败做好准备。 后端不可避免地会崩溃，或者特定的端点在其余的仍然工作时会发生故障，这是不可避免的。 您应该区分出应用程序中的哪些呼叫是至关重要的，其中失败构成显示应用程序范围的错误屏幕并显示一条消息，以便稍后再试；哪些呼叫可以通过正常的体验降级进行处理（例如，使用该功能将按钮变灰悬停错误消息说它当前不可用）。

如果将后端拆分为多个微服务，则端点子集发生故障的可能性会更高。 如果您的后端只是一台服务器，则单个故障可能会使每个端点崩溃。 无论哪种方式，一个好的前端都需要始终将对后端端点的调用包装在try-catch中，并准备好错误路径。 Javascript无法恢复。 如果不处理，该应用程序将崩溃。

HTTP

后端和前端应使用适当的HTTP状态代码（在某种程度上）。 希望您的后端不会将每个错误都视为400，但为简单起见会有一些错误。 前端应该知道后端计划返回的每个状态。 不要解析错误消息以检测登录失败，401更一致。

如果您收到400，则不要重试完全相同的请求，因为它可能无法再使用，但是500可能表明服务器刚刚重新启动，重试将成功。

HTTP的其他属性值得了解：

1. 如果完成时间太长，服务器可以关闭HTTP请求。 如果您认为某些任务可能会达到此限制（大约20秒是一个很好的经验法则），则应从单个请求响应切换为请求，然后再轮询结果，或者使用其他机制（例如Web套接字）。
2. 如果要将大量数据发送回服务器（例如视频），则应使用多部分HTTP请求，该请求会将数据拆分为多个要发送的块。
3. 偶尔出现的意外情况是存在URL限制大小。 某些前端会将带有查询参数的数据传递回服务器，但是如果长度超过2048个字符，则必须切换为在HTTP正文中对其进行编码。

委托业务逻辑

如果您要构建的功能的某些业务逻辑既可以在前端也可以在后端完成，那么应该在哪里编码呢？ 通常，您应该在后端执行此操作。 原因：

1. 可以更快地更改后端-在所有服务器上进行一次部署并且过时的业务逻辑已消失，但是前端客户端在用户的手中，而且部署并不意味着您仍不会运行中断的业务逻辑在生产中。
2. 如果业务逻辑需要计算能力，则很难测试客户端可能运行的计算机范围。 如果仅使用公司提供的顶级Macbook进行测试，您将不会意识到100美元的Chromebook的计算速度会降低多少。
3. 将业务逻辑锁定在后端更加安全。 假设您具有仅专业用户可以访问的功能。 如果仅在前端上对限制进行编码，则有人可能会通过其进行的API调用来对您的客户端进行反向工程，然后访问功能。 这在野外发生（例如，绕过限制的音乐播放器）。

跨源请求

作为安全协议，如果对后端的请求来自其他域，则由于是“跨源请求”，因此将被拒绝。 这称为“相同来源策略”。 因为端口是域的一部分，所以这使开发人员陷入困境，而且人们通常在另一个端口上为其前端和后端运行NPM / Yarn服务器，因此使每个请求都是跨源请求。

解决方案：

1. 将您的服务器域映射到开发环境的主机配置中的某些主机名。
2. 以开发中为true且生产中为false的环境变量为条件，在服务器上启用跨源请求。
3. 将您的开发领域列入白名单是一个例外。

跨站点请求伪造是一种攻击的名称，该攻击是从另一个站点发起的用户发出未经授权的请求。 例如，您单击某个网站上的按钮，它会执行Javascript尝试使您在银行网站上执行请求。

为防止这种情况，服务器会为每个会话提供一次性令牌，因此尝试将由于没有令牌而失败。 这称为CSRF令牌。 将其附加到授权请求的标头。

快取清除

每个请求在到达后端的过程中都要经过多个缓存。 如果您是第一次访问网站，请等待其加载，然后重新加载页面，该Web应用程序的加载速度将比第一次加载时快，这是因为浏览器的缓存资产（如favoritewebsite.com/static/script.js）。 如果要更改script.js怎么办？ 您更改文件名。

假设您在index.html引用的内容中将script.js切换到script.js？v = 2。 缓存的script.js变得无关紧要，因为永远不会再有其他请求（除非index.html被缓存！

对index.html的请求需要在后端无效）。 现代的构建管道包括每个构建的缓存清除，这就是为什么大多数Javascript文件输出看起来像script.4e885f13.js的原因。 通常，这仅适用于样式表和脚本，但是您也可以将其应用于图像和其他资产。

不过，资产通常很少进行更改，出于性能原因，值得将它们排除在自动缓存清除之外，并在需要时手动进行更新。

结论

前端工程师不需要太多了解后端就可以有效。 您想成为T形-在一个垂直领域内拥有丰富的专业知识，对各种事物都有一定的了解。 您永远都不知道后端的主题如何使您作为前端工程师的技能受益。 想更多地了解前端和后端之间的连接？ 在https://terrastruct.com上绘制一些图表-确保您了解某些东西的唯一方法是自己向他人解释。

先前发布在https://terrastruct.com/blog/what-frontend-engineers-should-know-about-backend/

From: https://hackernoon.com/what-frontend-engineers-should-know-about-backend-ks7r3ylc