React：我们即将和后端 API 告别？( 三 ) _API

文章插图

而如果后端可以运行 React 组件，直接渲染 React 节点树到前端，就不需要所谓的 API 的概念了。

文章插图

后端运行 React 组件并不是什么新鲜事，我们在 SSR（Server Side Rending）早就习以为常了，但是需要特别注明的一点是，在 SSR 中，后端是运行了 React 组件，生成了一份初始状态的 html，但这份 html 是没有可交互性的，它只是为了让用户能尽早看到页面而做的一种改良式的、修修补补一样的优化。
而 Server Components 所带来的，是我们可以把同一个项目中，一部分的组件作为 Server Components，另一部分组件，作为 Client Components，因此我们可以既享受到后端内部调用带来的便捷、可维护性，又能保证页面的可交互性几乎没有任何妥协。
如果你用过 php 或 Django，那你肯定非常熟悉这种模式：后端直接渲染 html 内容，浏览器只负责显示，用户点击按钮，那就重新请求、重新渲染页面，如果页面上需要一些复杂的动态交互，比如让用户可以把一个列表展开/收起，或者是点击某个按钮之后展示一个模态框，那可以借助于 jQuery 来实现。
PHP + bootstrap + jQuery，现在，Server Components 就像是这套范式的升级版，可以被称为一种全新的“全栈”开发模式。
因为是在后端环境下，这些 Server Components 可以使用全部的后端能力，不管是中间件，还是其他后端微服务的调用，甚至是 db 的访问（当然可以直接跑 SQL，但是更好的实践是通过一个数据中间层），都可以实现。这样一来，我们就可以直接把数据从源头获取，放到 React 组件的上下文中，那自然就不需要传统意义上的 API 了。
更准确的说，API 并未消失，我们其实也不会和 API 就此说再见，而是让它换了一种形式。有模块化的地方，就会有 API，Restful 的 http 网络请求固然是 API，但中间件暴露出来的方法，浏览器提供的 Date 对象，node 提供的文件读取函数，db 提供的 SQL，这些全都是 API 。
在这种新架构下，API 变成了后端里业务应用和上游服务之间的调用，变成了 Server Components 和 Client Components 之间的 props 传递，前者让 API 变得更加干净、更符合单一职责的原则，而后者让 API 变得自然到你几乎感知不到。
所以：

Server Components 允许我们不再按照前端 - 后端进行模块的拆分，而是依照业务应用 - 底层服务来进行更合理的模块拆分。从而可以理论上降低模块之间的沟通成本（因为目前还没有办法实践证明）。
由于 Server Components 是在后端运行组件，直接通过网络传输给前端进行渲染，因此很多大体积的包（例如 markdown 渲染、html sanitize）都不需要在前端下载和运行，从而很大程度上降低包体积。
由于底层 db 或上游服务的调用都是发生在后端内部的，因此即便出现并发请求，所带来开销也远远小于前端并发调用后端的 Restful API 。
同理，请求瀑布流的问题也会因为调用开销降低而消失或减轻。

想象如果大胆想象一下的话，未来的研发模式可能这样的：
开发者将不会再区分前端和后端，而是区分为业务应用开发和上游服务开发。现在的后端开发将（真正地）不再需要关注视图逻辑，只聚焦于底层业务逻辑，为前端提供清晰好用、原子化的服务/接口；而现在的前端开发将会拓展到横跨前端和后端（代码运行环境上），负责的是在后端封装好的一个个原子化的底层能力上，构建视图层，而我们也需要一套全新的框架和基础设施，来适配 Server Components 。
目前，Server Components 还没有正式发布，而即便正式发布之后，也还有长长的工程化落地的路要走，Server Components 增加了很多额外的限制，server、client、shared 的区分也可能会带来一些理解成本。缓存、性能、server 重新渲染时的增量更新策略、发布时的可灰度性和可回滚性、业务中边界情况的处理，还有很多的问题需要去解决，还有很多的未知尚未被验证。
参考资料[1] 演讲视频: