用于简单转换的 GraphQL 解析器

Question

情况：我们有一些类型的 GQL 可以提供图标名称。名称与不同的数据属性（名称、id、类型、严重性...）区分开来。这是通过简单的字符串转换来完成的。图标的末尾是 CDN 中某处的一些统一的 svg 文件。资源看起来像“Php”、“Apache Server”等，解析的图标名称（键）是“php”、“apache-server”等。

问题是什么是更好的模式

A.为每种类型添加一个名为“icon”的解析器，并在服务器端提供所有转换。这意味着 GQL 更加健谈、传输更多数据并且 FE 代码更加简单。主要论点是GQL应该面向客户端，数据最好保持一致。

B.或者按原样提供数据，并在查询结果和以特定于对象的方式渲染之间将其转换为 FE 上的图标名称。这意味着 API 上的冗余更少，而 FE 代码的复杂性更高。这种方法的主要论点是图标是客户端的资源，与服务器无关。

请问A和B如何抉择？

（该系统是一个针对数千个并发用户的商业智能工具）

Answer 1

看来您正在遇到一个典型的用例来实现前端模式的后端，您在“服务器”上执行一些操作以满足“客户端”的特定需求。

有几个因素需要考虑。

模式A

数据生命周期

地图的“图标”、“类型”、“严重性”似乎是相对恒定的。如果值发生变化，您是否愿意发布新版本，或者仅在数据级别上进行操作对您的用例有利？

客户端、服务器和 CDN 同步部署，或者您的用例允许客户端和服务器之间使用不同的版本？

在这种情况下，服务器端是唯一的选择。

表现

我也在研究 BI 和大数据工具:)。太多的服务器端操作可能会造成混乱，但在这种情况下，我强烈建议进行负载测试。GraphQL 可以以非常低的占用空间进行解析，而不会对服务器性能产生相关影响。

关注点分离

我从您的描述中推断出您的应用程序不是基于微服务的，并且没有前端后端。

如果你想在后端引入前端计算，你必须将其与其他部分在逻辑上分开。

我强烈建议您使用模块化整体范例，即使您在服务器上执行客户端操作，也可以很好地分离关注点。

B型

SVG 生命周期

你说SVG在CDN上，资源是你提供的还是像fontawesome这样的第三方资产？

如果您的团队具有不同的技能，这可能会成为一个问题：npm update不应影响服务器或数据库活动。

请记住如何维护 SVG 和图标图。

复杂

在前端进行此映射对客户端性能没有太大影响，而且复杂性非常低且本地化。

如果您使用的是 Web 客户端，ES6 功能允许您在客户端通过映射和解构进行非常可读的映射：“复杂性”仅在最后 3 行，并且在客户端执行，因此不会影响您的 BI 服务器。

const resources = {
  php: {
    name: "Php",
    type: "application",
    severity: "warn",
  },
  "apache-server": {
    name: "Apache Server",
    //
  },
};

const genericResource = {
  id: "generic",
  name: "unknown resource",
  type: "application",
  severity: "warn",
};

const grapQLRequest = async () =>
  Promise.resolve().then(() => [
    { resource: "php", message: "some string", timestamp: "" },
    { resource: "apache-server", message: "some string", timestamp: "" },
    { resource: "new-resource", message: "some string", timestamp: "" },
  ]);

const handler = async () => {
  const result = await grapQLRequest().then((data) =>
    data.map((x) => ({
      ...x,
      resource: {
        id: x.resource,
        ...(resources[x.resource] || genericResource),
      },
    }))
  );

  console.log(result);
};

void handler();

将资源放在靠近其自身用途的地方

一种非常常见的代码味道是霰弹枪手术，通过这种方法，您可以使您的地图非常接近其自身的用途。

这可以更具可读性和可维护性，您不需要考虑关注点分离。

国际海事组织

我对您现有的架构和模式了解甚少，我强烈建议您对现有环境进行非破坏性的选择。

站在你的立场上，我可能会选择选项 B，并做出一些假设：

• 图标比较稳定
• 团队由具有特定技能的人组成

奖励：如果列表很小，您可以将其嵌入到您自己的工件中，否则您可以执行异步导入，仅在需要时导入资源。