05-可能并不需要SSR

12.3　可能并不需要SSR

尽管SSR有一些潜在的好处，但你应该只在真正需要的时候才把它构建到应用中，因为它会引入显著的复杂性（取决于其集成的深度）。在本章我们将实现一个基本的最简版SSR（服务器端渲染）来熟悉概念，但要构建能够处理SSR所有细微差别的健壮的专门实现，则要求深度的技术参与。

至少有几个原因可以解释为什么集成服务器端渲染会增加复杂度。下面是其中一些。

• 需要以某种方式同步服务器与客户端，以便客户端了解其何时接管。这可能涉及设置HTML、事件处理程序以及客户端可能需要的更多内容。身份验证的实现也需要考虑来自服务器或客户端的请求，这些请求可能需要做些更改。
• 客户端和服务器在不同的范式内运作，这些范式并非总是那么容易相互映射（例如，没有DOM，没有文件系统，等等）。必须协调切换和渲染，并确保没有使用或者已经正确处理了依赖浏览器环境的组件。
• 尽管有一些例外存在，React（以及任何JavaScript）非常可靠地运行在Node.js运行时上。这可能会将客户端和渲染它的服务器耦合在一起，因为它们现在都需要支持JavaScript。这可能是一件好事，但它的确意味着你正比正常情况下更多地将自己与JavaScript语言/平台绑在一起。
• 微调SSR可能需要对客户端和服务器进行专门调优。性能提升通常是通过关注特定功能的小而渐进的提升来实现的，且几乎总是涉及权衡。这有时意味着进行快速更改时灵活性更差以及维护过程更复杂。服务器端渲染为这个过程又增加了一个方面。

总的来说，这里谨慎的主要原因是“仅用所需”这样的观念。我不希望读者认为如果不使用SSR，React应用就不完整或者“不够React”。最好的工程决策过程包含对所涉及权衡的全面思考（不只是其他人用什么或者流行什么！），这一观点在这里也适用。一个例子可能是作为个人副业项目正在编写一个简单的博客应用程序。事实上，如果不是Netflix，就不需要Netflix的基础设施和编排技术。即便如此，也不是所有大公司都做SSR。编写本书时，甚至Instagram似乎都没有用React做SSR，而他们在React上投入巨大。仅用所需。