介绍

最近，OpenAI 宣布对其技术栈进行重大调整，从 Next.js 转向 Remix。这一决定引起了开发者社区许多人的关注，引发了人们对为何进行这样的转变的疑问。在本文中，我将基于探索他们的代码库并研究他们如何在应用程序中实现 Remix 来分享我的想法和见解。虽然我没有收到任何内部信息，但我对技术细节的深入研究很好地解释了 OpenAI 为何做出这一转变。

了解 OpenAI 对 Remix 的使用

OpenAI 的 ChatGPT 界面现由 Remix 提供支持，主要作为客​​户端渲染应用程序运行。与将完整格式的 HTML 从服务器传输到浏览器的传统服务器渲染设置不同，OpenAI 的方法以客户端渲染为中心。这意味着大部分繁重的工作发生在客户端而不是服务器上。

访问该网站后，您会收到少量 HTML，包括一些元标记和一组预加载的图像和 JavaScript 文件，这些对于客户端操作至关重要。虽然 Next.js 以其强大的服务器端渲染 (SSR) 功能而闻名，但 Remix 还擅长创建单页应用程序 (SPA)，其中大多数交互都发生在浏览器中，使其成为客户端渲染的理想选择。

Remix 与 Next.js：路由优势

OpenAI 选择 Remix 的一个关键原因是其出色的路由系统。Remix 由 React Router 的创建者开发，路由是 Remix 的核心优势。OpenAI 的应用程序使用大约 60 条路由，Remix 以优化客户端渲染的方式处理路由，同时高效管理每条路由的数据加载。

Remix 的“加载器”功能特别强大，允许服务器在呈现路由之前收集路由所需的所有数据。这与 Next.js 不同，在 Next.js 中，应用程序可能会先加载 JavaScript，然后意识到需要通过 API 获取其他数据，这可能会减慢初始加载时间。通过使用 Remix 的加载器，OpenAI 可确保初始页面加载更快、更流畅，因为所有必需的数据都是预先获取的，并只需一步即可交付。

为什么 Remix 对 OpenAI 有意义

转向 Remix 的决定可能取决于以下几个关键因素：

1. 客户端渲染优化：OpenAI 的应用程序并不严重依赖 SSR。相反，Remix 允许他们在客户端处理大部分渲染，服务器主要提供数据。这与 OpenAI 的架构相一致，其中大部分工作（例如模型交互和 API 调用）发生在单独的后端系统上。Remix 能够充当与这些后端无缝集成的轻量级前端框架，这使其成为自然之选。
2. 加载器效率：Remix 的加载器提供了一种在首次渲染时加载数据的高效方法。在 OpenAI 的案例中，这意味着当您加载页面时，会立即为您提供所有必要的信息（例如用户数据、会话令牌等），从而最大限度地减少延迟并增强用户体验。
3. API 调用灵活性：OpenAI 的 Remix 应用程序与外部 API 交互，后者处理大部分后端逻辑。他们不依赖 Remix 进行服务器端操作，而是使用 Remix 作为从这些 API 获取数据的前端。这种关注点分离使 OpenAI 能够将其 API 和后端逻辑与前端分离，从而实现更好的可扩展性和维护性。
4. 轻量级框架：Remix 在 Vite 上运行，Vite 以快速和轻量级的开发环境而闻名。Vite 的速度和灵活性可能会吸引 OpenAI，尤其是与在 Webpack 上运行的 Next.js 相比。尽管 Webpack 取得了进步，Next.js 也在 TurboPack 等工具上不断努力，但 Vite 的简单性和性能可能会提供更无缝的开发人员体验。

服务器端渲染和 SEO 怎么样？

鉴于出于 SEO 和性能原因而流行的服务器端渲染，有些人可能想知道为什么 OpenAI 选择放弃 Next.js 的 SSR 功能。答案很简单：ChatGPT 不需要 SSR 带来的典型 SEO 优势。由于该应用程序主要是一个工具，而不是一个内容驱动的网站，因此 SEO 不是问题。相反，OpenAI 专注于快速、流畅的客户端交互，而 Remix 可以高效处理这些交互。

后端和基础设施考虑因素

从技术细节来看，OpenAI 的后端 API 很可能托管在自定义基础设施上，由使用 Envoy 和 CDN（Azure）的代理服务器支持。Remix 与这些 API 交互以检索必要的数据，但不直接管理服务器端逻辑。决定在 Express 服务器上运行 Remix 也凸显了 OpenAI 对轻量级和高效服务器端操作的偏好。

虽然他们之前曾将 Vercel 与 Next.js 结合使用，但没有迹象表明他们现在正在使用 Vercel。相反，他们似乎选择了更定制的基础设施设置，由 Cloudflare 处理部分负载平衡和流量分配。

顺风和造型选择

OpenAI 继续使用 Tailwind CSS 进行样式设置，这与他们的 Next.js 实现保持不变。不过，值得注意的是，他们没有使用 Remix 的其他一些功能，例如处理表单提交和服务器端功能的操作。这表明他们的重点纯粹是优化数据加载和客户端交互。

最后的想法：为什么要使用 Remix？

总而言之，考虑到 OpenAI 的架构需求，转向 Remix 是合情合理的。Remix 提供了灵活的客户端渲染功能、强大的加载器系统（用于高效数据获取）以及与其 API 驱动的后端的无缝集成。此外，Remix 的路由系统和在 Vite 上运行的能力为 OpenAI 用户所期望的交互类型提供了轻量级且高效的解决方案。

虽然 Next.js 仍然是一个强大的工具，但 Remix 似乎提供了 OpenAI 为 ChatGPT 所需的特定优势，因此迁移成为合乎逻辑的一步。

希望我们能从 OpenAI 那里听到更多关于这一转变的消息，但根据我的探索，Remix 显然更适合他们的目标，即通过强大的路由和数据管理实现快速的客户端渲染交互。