GraphQL图标名转换选型：服务端Resolver还是前端处理

现有部分GraphQL（GQL）类型可返回图标名称原始值，原始值取自name、id、type、severity等不同数据属性，需经简单字符串转换，匹配CDN上存储的统一SVG图标资源对应的键名。例如原始资源值为"Php"、"Apache Server"时，转换后的图标键名为"php"、"apache-server"。

• 方案A：为每个类型新增名为"icon"的resolver：所有转换逻辑在服务端完成。该方案下GraphQL接口传输字段更多，前端代码更简洁直接，支撑理由为GraphQL应面向客户端设计，可更好保障数据一致性。
• 方案B：服务端直接返回原始数据：前端在获取查询结果后、渲染阶段按对象规则自行转换为图标名。该方案下API冗余度更低，但前端代码复杂度更高，支撑理由为图标属于客户端侧资源，与服务端逻辑无关。

面向千级同时在线用户规模的商业智能工具场景，应如何在上述两种方案中做出合理选型？

系统背景：千级并发用户量级的商业智能工具

针对这个场景，优先选择方案A，也就是服务端新增icon字段resolver统一做转换，核心判断依据都是实际工程落地踩坑总结的：

1. 性能开销完全可以忽略。字符串大小写转换、特殊字符替换这类操作是最轻量的计算逻辑，千级并发下给服务端带来的CPU压力微乎其微，根本不会成为服务瓶颈，完全没必要为了这点可以忽略的成本把逻辑甩给前端。
2. 长期维护成本差距极大。商业智能工具一般不会只有单一Web端，通常会覆盖桌面客户端、嵌入式SDK、甚至后续的移动端，如果把转换逻辑放在前端，每一端都要单独维护一份映射表、写一套转换逻辑。后续只要新增业务实体类型、调整图标命名规则，就得所有端跟着改代码、走发版流程，漏改任何一端就会出现图标加载失败的低级问题，排查修复浪费的人力，比服务端写个resolver的成本高几十倍。
3. 所谓"接口冗余"的问题在GraphQL体系下根本不存在。GraphQL原生支持字段按需请求，不需要icon字段的客户端完全可以在查询语句里不声明这个字段，不会有多余的数据传输开销。反过来"图标属于客户端资源和服务端无关"的说法站不住脚：图标和业务实体的映射规则是和数据属性强绑定的，不是可以随便改的纯前端样式逻辑，本来就属于服务端应该屏蔽的底层数据细节，完全符合GraphQL面向客户端设计的初衷。

只有一种例外情况可以考虑方案B：如果你们的图标体系支持租户级自定义、不同客户端可以配置完全独立的图标映射规则，服务端根本没法维护统一的转换逻辑，这时候才适合返回原始值让各端自行处理。只要全局图标映射规则是统一的，服务端统一实现的投入产出比远高于前端分散实现。

内容的提问来源于stack exchange，提问作者Tomas Randus