React已经成为全栈型框架，前后端通吃。你准备好了吗？
React 已经添加了服务器组件和服务器操作，正在演变成一个全栈框架。它是曾经榜单中最流行的前端框架，现在成功地弥合了前后端之间的鸿沟，统治着两边的开发者。
我写这篇文章是因为以下的插图一直萦绕在脑海中。
2010 年，框架之战以 Backbone、Knockout 和 Ember 作为开端，随后 Angular 和 React 相继出现，没有人能够预测结果。
很长一段时间内，客户端渲染 (CSR) JavaScript 应用程序占据主导地位。这些应用程序也称为单页应用程序 (SPA)，通常只是一个链接到大型 JavaScript 文件的小型 HTML 文件，直到代码分拆的出现。
在此期间，前端开发由各种 JavaScript 框架和库主导（Web 开发人员喜欢进行此讨论），而后端通常不与特定语言绑定，因为 REST 已经是 API 通信的标准。
在我担任自由 Web 开发人员的这些年里，我主要使用 .NET、Java、Python 和 PHP 作为后端。就我个人而言，我只在新建项目或小型项目时在后端看到过 TypeScript/JavaScript，我可以控制后端。然而，随着全栈 React 的兴起，这种情况正在改变。
回顾过去，我们发现开发人员对 2010 年至 2020 年期间的看法因其职业生涯开始时间的不同而存在差异，这很有趣。
2010 年之前入行的开发人员发现自己处于服务器端渲染 (SSR) 环境中，并且似乎对最近转向服务器端技术感到更适应。相比之下，许多其他人花了近十年时间只在客户端渲染 (CSR) 应用程序中使用 REST API。现在他们不知道该如何看待新的全栈 React 世界。
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⡶⠛⠛⢦⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⠋⠀⠀⠀⠈⣧⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⠴⠞⠛⠉⠉⠉⠉⠉⠉⠛⠒⠾⢤⣀⠀⣀⣠⣤⣄⡀⠀⠀⠀⠀⠀⠀⣠⡶⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠛⢭⡀⠀⠈⣷⠀⠀⠀⠀⠀⡴⠋⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⢦⢀⡟⠀⠀⠀⠀⣾⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⢻⡅⠀⠀⠀⢸⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢻⣄⣀⠀ 有人忘记了 SPA 吗？⣾⠀⠀⣠⣤⣤⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣤⣄⠀⠀⠀⠀⠀⠀⠀⠸⡇⠉⣷⣿⠀⠰⣿⣿⣿⡗⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿⣿⠀⠀⠀⠀⠀⠀⠀⠀⣧⡴⠋⣿⠀⠀⢸⠛⢫⠀⠀⢠⠴⠒⠲⡄⠀⠀⠀⠀⡝⠛⢡⠀⠀⠀⠀⠀⠀⠀⢰⡏⠀⠀⢸⡄⠀⢸⡀⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡇⠀⢸⠀⠀⠀⠀⠀⠀⡼⣄⠀⠀⠀⢳⡄⠀⡇⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢹⠀⢸⠀⠀⠀⠀⢀⡼⠁⢸⡇⠀⠀⠀⠀⠙⢦⣷⡈⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⠀⠈⡇⠀⣀⡴⠟⠒⠚⠋⠀⠀⠀⠀⠀⠀⠈⠛⠾⢤⣤⣀⣀⡀⠀⠀⠀⠀⣀⣈⣇⡤⣷⠚⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⠇⠀⠩⣉⠉⠉⠉⣩⠍⠁⠀⢷⣟⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⡟⠐⠦⠤⠼⠂⠀⠸⠥⠤⠔⠂⠘⣿⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣸⣧⡟⠳⠒⡄⠀⠀⠀⡔⠲⠚⣧⣀⣿⠿⠷⣶⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠻⣄⢀⠀⠀⡗⠀⠀⠀⡇⠄⢠⠀⣼⠟⠀⢀⣨⠇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠙⢶⠬⠴⢧⣤⣤⣤⣽⣬⡥⠞⠛⠛⠋⠉⠀⠀⠀⠀⠀⠀⠀⠀但让我们回到正题上！近年来，TypeScript 已成为行业标准，为前端开发人员提供了一种类型化且更强大的编程语言。一旦开发人员接受了 TypeScript，就再也没有回头路了。
代码中一个相对较小的改变竟然会对个人和整个行业产生如此重大的影响，这真是令人着迷。
然而，TypeScript 对 REST 的影响涉及许多临时解决方案。虽然 OpenAPI（以前称为 Swagger）以前就存在，允许团队记录 REST API，但它的主要目的现在变成了生成类型化的 API 接口。尽管有可能在客户端-服务器架构中创建完美类型的接口，但根据我多年担任自由 Web 开发人员的经验，许多项目从一开始就未能正确实现它。
个人说明：可能有些开发人员对 OpenAPI 驱动的架构有积极的体验，但不幸的是我不是其中之一。
看到 TypeScript 如何改变这里的情绪，这相当有趣。一方面，使用 REST（以及用于文档目的的 OpenAPI）的非类型化 SPA 似乎“还行”。然而，一旦 TypeScript 成为标准并被视为常态，生成的类型接口就会变得难以使用，因为人们已经习惯了前端代码库中的更高标准。
生成类型接口的缺点很明显：
总有一个世代相传的过程生成的输出很混乱根据初始设置，生成的代码并不总是正确的介绍一位老朋友：RPC。
远程过程调用并不新鲜，并且由于 tRPC而变得流行，它们在 React 生态系统中越来越受欢迎。我作为一名独立开发人员在80k 行代码应用程序上工作了半年（2023 年）。从经验来看，调用后端函数来读取和写入数据是一种启示。在技术堆栈的两侧都使用 TypeScript 的环境里，我从未感到过如此高效的工作效率。
就我个人而言，几年前，只有在（生成的）类型化 GraphQL 架构中，我才感到了类似的高效。
有一年的时间（2023 年），我无法想象有什么比 tRPC 更好。仅使用一个函数来调用后端以读取和写入数据，这感觉这是革命性的。这就是我所需要的一切吗？不。对我来说，真正的突破来自 2024 年的服务器组件和服务器操作，它们不仅通过调用它，还能够在另一端实现和执行代码，从而弥合了与服务器之间的差距。
服务器组件允许我们在服务器上执行 React 组件，从而能够从数据源（例如数据库）直接访问，然后使用 JSX 返回 UI。
import { getMessages } from '@/messages/queries/';const MessageList = async () => { const messages = await getMessages(); return ( <ul> {messages.map((message) => ( <li key={message.id}>{message.text}</li> )) } </ul> ); };export { MessageList };另一方面，服务器操作在后台创建 HTTP API 节点，可以通过执行函数像远程过程调用一样调用这些节点。
服务器组件和服务器操作将 React 转变为全栈框架，将前端转变为全栈环境是多么激动人心的时刻！
React 本身仅提供服务器组件和服务器操作的原语和规范。基于 React 构建的元框架可以通过其打包器弥补差距，后者负责解释客户端和服务器之间的指令（即'use client'和'use server'）。
此外，Next.js 是 React 的领先元框架，率先实现了服务器组件和服务器操作。尽管 Next.js 之前已经支持服务器端渲染 (SSR)，但服务器组件和服务器操作现在使开发者能够访问服务器端资源，例如数据库与消息队列。
这些标志着 React 全栈开发的开始。随着开发者开始通过服务器组件和服务器操作直接访问数据库，未来将有一个学习曲线来克服简单 CRUD 应用程序之外的复杂性。
通过全面的培训，前端开发人员很快就会掌握使用层、设计模式和最佳实践来实现后端架构。因为说句实话，没有人希望在 React 组件中看到 ORM 函数调用。
我对这种新范式转变感到兴奋！准备好迎接新时代吧，React 开发人员将实现从 UI 到数据库的垂直功能。我已经为这次旅程做好了准备，希望你也一样 :)
