Hydro 项目中 API 页面跨域查询问题的分析与解决

在 Hydro 在线评测系统的开发过程中，我们发现了一个关于 API 查询的有趣问题。当用户在特定域的 API 页面进行查询时，系统并没有正确识别当前域，而是默认调用了主域的 API 端点。这个问题看似简单，但实际上涉及到了 Hydro 系统的多域架构设计和 API 路由机制。

问题现象

在 System Test 域的 API 测试页面（/d/system_test/api）中，当用户尝试查询该域下的题目（如 P9）时，系统返回了空结果。然而，当查询主域的题目（如 H1000）时，却能正确返回题目信息。这表明 API 请求被错误地路由到了主域而非当前所在的 System Test 域。

技术背景

Hydro 作为一个支持多域的在线评测系统，其架构设计允许不同的域（如主域、比赛域、测试域等）拥有各自独立的数据集。这种设计在提供灵活性的同时，也对 API 路由机制提出了挑战。

在 Web 前端开发中，API 端点通常需要根据当前访问的域动态确定。理想情况下，前端应该能够自动识别当前所在的域，并将 API 请求发送到对应的后端服务。

问题根源分析

经过深入排查，我们发现问题的核心在于 API 测试页面的前端实现。当前的实现存在以下两个关键问题：

1. 硬编码的 API 端点：API 测试页面直接使用了主域的固定 API 端点，而没有根据当前访问的域动态生成正确的端点地址。

2. 缺乏域感知机制：前端代码没有从当前 URL 中提取域信息，导致所有请求都被默认发送到主域。

解决方案

针对这个问题，我们提出了两种可行的解决方案：

1. 动态端点生成：修改前端代码，使其能够从当前 URL 中提取域信息，并动态构建正确的 API 端点。例如，对于 /d/system_test/api 这样的路径，应该自动使用 /d/system_test 作为 API 的基础路径。

2. 用户可选域：在 API 测试页面添加域选择器，允许用户手动指定要查询的域。这种方法虽然增加了用户操作的复杂度，但提供了更大的灵活性。

最终，我们选择了第一种方案作为主要解决方案，因为它更符合用户的直觉预期，能够提供无缝的使用体验。

实现细节

在具体实现上，我们通过以下步骤解决了这个问题：

1. 从 window.location.pathname 中解析出当前域标识（如 system_test）。
2. 使用解析出的域信息动态构建 API 端点 URL。
3. 确保所有 GraphQL 请求都使用正确的域特定端点。
4. 添加错误处理机制，在无法确定当前域时提供明确的错误提示。

技术启示

这个问题的解决过程给我们带来了一些重要的技术启示：

1. 避免硬编码：在涉及多租户或多域的系统设计中，应当尽量避免硬编码特定域的配置。

2. 上下文感知：前端应用应当充分利用浏览器提供的环境信息（如当前 URL）来做出智能决策。

3. 一致性原则：用户界面行为应当保持一致性，在特定域下的操作应当默认作用于该域。

总结

通过解决这个 API 跨域查询问题，我们不仅修复了一个具体的功能缺陷，更重要的是完善了 Hydro 系统的多域支持架构。这个案例也提醒我们，在开发支持多租户或多域的系统时，需要特别注意上下文感知和动态路由的实现。

对于开发者而言，理解系统架构的边界和上下文传递机制至关重要。只有全面考虑这些因素，才能构建出行为一致、用户体验良好的分布式系统。