首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

GraphQL错误:应为GraphQL命名类型,但得到的是:{}

GraphQL错误信息“应为GraphQL命名类型,但得到的是:{}”通常表示在GraphQL模式定义中存在问题,具体来说,某个字段或类型预期应该是一个命名类型(Named Type),但实际上得到的是一个空对象类型({})。这种情况可能发生在模式定义、解析器实现或客户端查询中。

基础概念

GraphQL命名类型:在GraphQL中,命名类型是指具有明确名称的类型,如StringInt、自定义的User类型等。

空对象类型:{} 表示一个没有任何字段的类型,这在GraphQL中通常是不合法的,因为它没有提供任何信息。

可能的原因

  1. 模式定义错误:在GraphQL schema中,某个字段被错误地定义为非命名类型。
  2. 解析器问题:解析器返回了一个空对象,而不是预期的命名类型。
  3. 客户端查询错误:客户端发送的查询请求中,某个字段期望得到命名类型,但实际返回的是空对象。

解决方法

检查模式定义

确保所有的字段都正确地指向了命名类型。例如:

代码语言:txt
复制
type Query {
  user(id: ID!): User # 确保User是一个命名类型
}

type User {
  id: ID!
  name: String!
  email: String!
}

检查解析器

确保解析器返回的是正确的类型。例如:

代码语言:txt
复制
const resolvers = {
  Query: {
    user: (_, { id }) => {
      // 假设getUserById是一个函数,它返回一个User对象
      return getUserById(id);
    }
  }
};

检查客户端查询

确保客户端发送的查询请求是正确的。例如:

代码语言:txt
复制
query GetUser($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}

应用场景

这种错误通常出现在构建GraphQL API时,特别是在定义复杂的模式和实现解析器逻辑时。确保模式的一致性和解析器的正确性对于避免这类错误至关重要。

示例代码

假设我们有一个简单的GraphQL服务,定义了一个User类型和一个查询用户的字段:

代码语言:txt
复制
# schema.graphql
type Query {
  user(id: ID!): User
}

type User {
  id: ID!
  name: String!
  email: String!
}

对应的解析器可能如下所示:

代码语言:txt
复制
const users = [
  { id: '1', name: 'Alice', email: 'alice@example.com' },
  { id: '2', name: 'Bob', email: 'bob@example.com' }
];

const resolvers = {
  Query: {
    user: (_, { id }) => users.find(user => user.id === id)
  }
};

确保在实现和使用GraphQL服务时,所有的类型和字段都正确无误,可以有效避免“应为GraphQL命名类型,但得到的是:{}”这类错误。

相关搜索:GraphQL错误:未定义应为GraphQL类型GraphQL错误:应为名为'FileUpload‘的用户定义的GraphQL标量类型,但未找到分析Hasura.GraphQL.Transport.HTTP.Protocol.GQLReq类型的构造函数GQLReq时,应为Object,但得到的是StringNestjs定义GraphQL对象类型得到此错误:架构必须包含唯一命名的类型,但包含多个名为"Address“的类型离开页面时,我得到:未处理的GraphQL订阅错误: GraphQL错误:未提供所需类型xxx的变量xx元素类型无效:应为字符串(...)但得到的是:对象GraphQL :必须为输出类型,但获得:未定义的错误Java返回错误:应为int,但得到的是字符串Xojo类型不匹配错误。应为字符串,但得到的是布尔值未处理的拒绝(错误):未定义应为GraphQL架构错误:应为“String”类型的值,但获得的是“Null”类型的值BigQuery语法错误:应为关键字JOIN,但得到的是")“Estimator.predict() TypeError:应为任何非张量类型,但得到的是张量在Apollo Express GraphQL中获取错误:错误:架构必须包含唯一命名的类型,但包含多个名为"DateTime“的类型嵌套错误:无法确定getProducts的GraphQL输出类型从我的python代码中进行graphQL突变,得到错误Jenkins groovy错误java.lang.IllegalArgumentException:应为命名参数,但得到[{returnStatus=true} ...](TiledWorldMap)错误:应为“double?”类型的值,但获得的是“String”类型的值颤动错误:应为'String‘类型的值,但获得的是'int’类型的值颤动错误:应为“File”类型的值,但获得的是“FilePickerResult”类型的值
相关搜索:
页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

用 GraphQL 快速搭建服务端 API

虽然在 RESTful API 里,我们可以通过路径命名笼统知道这个请求的作用,但使用 GraphQL 就可以在通过查询语句清晰、具体地描述这个请求的输入和输出。...Python 的变量命名规范),但客户端查询到的字段名就变成了像 crewNum 这样的驼峰风格。...但这么实现完了似乎心有不甘,好像还是有一些字段在数据库表里定义了,在 GraphQL 的对象类型 code 2.1 里被重复定义了?...错误处理 当查询语句出错或部分出错时,GraphQL 不会将错误直接上抛造成服务器 500 错误,而是依然会返回一个 json 对象,只是在这个对象中描述了发生怎样的错误。...当然这么做也有不好的地方,比如会改动用户的使用体验、需要额外的 UI/UX 在应对各种错误,但基本是一个比较平衡工作量和效果的方案。

2.5K30
  • 为什么我使用 GraphQL 而放弃 REST API?

    没有静态类型意味着要注意类型验证 无论如何努力避免这种情况,你迟早会遇到 JSON 属性拼写错误、发送或接收的数据类型错误、字段丢失等问题。...如果你的客户端和 / 或服务器编程语言是静态类型的,并且你不能用错误的字段名或类型构造对象,那可能没问题。...不容易记录和测试 上面提到的 Swagger 可能是目前最好的工具,但其应用还不够广泛。根据我的观察,更常见的情况是,API 文档单独维护。...此外,它非常简单:type块定义新的类型,每个块包含具有自己类型的字段定义。类型可以是非可选的,例如String!字段不能有空值,而String可以。字段也可以有命名参数,所以TodoList!...客户端库可以很容易地将 GraphQL 响应自动解包为所需类型的对象实例,因为从模式和查询可以提前知道响应形状。 GraphQL 是个时髦的东西,是一种时尚,对吗?

    2.3K30

    GraphQL到底怎么使?看看智联前端团队技术沉淀

    是语言无关的,所以 SDL 带有自己简单的类型系统。...} 预期数据会返回在 data 中,当有错误时,会出现 errors 字段并按照规范规定的格式展示错误。...在执行字段 Resolver 之后会得字段的值,如果值的类型为对象,则会继续执行其下层字段的 Resolver,如 contractedAuthor() 后得到值类型为 Author,会继续执行 name...() 和 articles() 以获取 name 和 articles 的值,直到得到类型为标量(String、Int等)的值。...强类型(字段校验):由于 JS 语言特性,强类型只能称为字段强类型校验(包括入参类型和返回结果),当数据源返回了比 Schema 多或少的字段时,并不会引发错误,而就算采用了 TypeScript 由于没有运行时校验

    2.3K20

    干货 | 携程基于 GraphQL 的前端 BFF 服务开发实践

    也就是说,用 Object 表达错误类型是含混的。code 和 data 的关系全靠服务端的逻辑来决定。...其实,在 GraphQL 中处理错误类型,有更好的方式——union type。...这个问题在 TypeScript 项目中影响重大,当 graphql-to-typescript 后,客户端会得到一份来自 graphql 生成的类型。由于服务端没有标记 !...由于非空类型的字段不能为空,字段错误被传播到父字段中处理。如果父字段可能是null,那么它就会解析为null,否则,如果它是一个非null类型,字段错误会进一步传播到它的父字段。...我们用如下查询语句查询 GraphQL 服务: 当 Grandchild 的 value 结果为 1 时,查询结果如下: 我们得到了符合 GraphQL 类型的结果,所有数据都有值。

    2.6K20

    你不知道的 GraphQL

    1+N查询问题 管理自定义Scalar类型 错误处理 日志 认证 & 中间件 Resolvers的单元测试 查询引擎的集成化测试 Resolvers拆分 组织Schemas 结语 目标 我们的目标是针对一个移动...所以你不能声明一个自定义类型用这两个关键字 - 它们是GraphQL预留关键字。你可能会对Query下定义的字段有个困扰,它们总是和实体类型名字一样 - 但这只是个习惯约定。...Graphql服务根据我们提供的schema定义,在执行请求携带的查询语句之前进行了必要的校验,如果我们的查询语句中包含了一个没有声明过的字段,我们会得到一个错误提醒: > curl 'http://localhost...但这种在响应中显示错误信息的简单处理,并没有在服务端记录错误日志。...但他们同时也靠售卖GraphQL相关服务来盈利,所以在盲目遵从他们提供的教程之前,你最好能有个备选方案。 开发一个GraphQL服务端需要比REST服务端更多的工作,但同样你也会得到加倍的回报。

    3.3K20

    《GraphQL 名词 101:解析 GraphQL 的查询语法》【译】

    : 使用GraphQL语言定义的一个或多个操作或者数据片段,类型是字符串。...这样,无论你是在网络日志中或者GraphQL服务器上发现错误,你都可以通过名字很轻松的在代码库中定位问题,而不是靠猜测(类似的工具有 Apollo Optics)。...因为GraphQL是静态类型的,它可以实时验证你是否传递了正确的变量。这正是你声明变量类型时所计划提供的能力。...片段定义(Fragment definition):定义一个片段是GraphQL文档的一部分。为了区别于我们下面会介绍的内联片段,它有时候也被称为片段命名。...,不同的业务场景只要基于同样一套基础业务数据模型就可以得到复用,在我看来,这才是 GraphQL 带来的最大改变和收益。

    3K20

    GraphQL 初体验,Node.js 构建 GraphQL API 指南

    虽然每一个 API 调用都可以异步完成,但你也必须处理它们的响应,无论是错误、超时甚至暂停页面渲染,直到收到所有请求数据。...Addresses 还定义了他自己的几个字段。(顺便说一下,GraphQL 模式不仅有对象,字段和标量类型,还有更多,你也可以合并接口,联合和参数以构建更复杂的模型,但本文中不会介绍)。...只需要 Schema 表达几行清晰的代码,就可以在客户端和服务端之间建立强类型的契约,这样可以防止你的服务接受虚假数据,并向请求着清晰地表明错误。...但这个缺点也是积极的:通过仔细设计你的 Graphql Schema,你可以避免在更容易实现(也更容易破坏)的 REST 端点中明显的陷阱,如命名的不一致和混乱的关系。...例如,无论成功与否,GraphQL 仅制定一个状态码 200.在这个响应中会返回一个特殊的错误键,供客户端解析和识别出错,因此,错误处理可能会有些棘手。

    8.3K40

    你还在用 REST API 吗?

    REST 的核心思想是,通过向资源的 URL 发送请求并获得响应(通常是 JSON,但这取决于 API)来检索资源。...灵活性 是使用 REST 的另一个优势,因为可以将其设计成处理不同类型的调用并返回不同的数据格式。 REST 的劣势 抓取过度——这是指 API 端点提供的信息比客户端所需要的要多得多。...除此之外,它还允许我们将不同的实体组合到单个查询中。 GraphQL 的优势 检索精确的数据,无任何多余数据。在 GraphQL 中,可以得到我们所请求的内容,这是一个很大的优势。...GraphQL 的劣势 对于简单的应用程序来说,设置类型、查询等可能有点 复杂,因为使用 REST 可以很容易地完成。 它使用的是 单个端点,而不是遵循 HTTP 规范进行缓存。...错误处理 REST 中的错误处理比 GraphQL 简单得多,GraphQL 通常会给我们一个 200 OK 的状态码,即使已经出现错误了。

    1.5K10

    你需要 GraphQL 吗?

    而且随着版本迭代,为了兼容现有业务,当前现有的 API 请求模块甚至还会出现很多 v1/v2的命名,导致接口命名不够统一简洁。...强调对象 GraphQL 强调的是描述一个对象,而非功能,而且可以按需取数据。...类型系统与自省 GraphQL的基本数据类型有五种:Int、Float、String、Boolean、ID。前四种比较常见,第五种ID类型对于我们编码时可以不必关注。...它是 GraphQL 标识对象时唯一的 key,会序列化成一段字符串。 通过类型系统,我们在开发时可以通过 GraphQL 开发工具清晰地看到对象属性及其类型,以及我们当前的输入哪里有误。...但如果你觉得你们的后期收益大于改变的成本,那就大胆去推动吧。

    2.2K70

    为什么GraphQL是API的未来

    这些在 GraphQL 中并不需要,因为你可以通过添加或删除类型来改进 API。 在GraphQL中,你所需要做的就是写新代码。可以编写新类型、查询和修改,而无需维护其他版本的API。...API,后来将其命名为 GraphQL。...我们稍后会详细了解它(本系列的下一篇教程)。看起来很神奇,但这就是 GraphQL! 使用 GraphQL,你只能获取所需的数据 没有过度获取或未被充分利用的信息,你只获取自己需的数据。...GraphQL 是未来 GraphQL 是一种开源查询语言,这意味着社区可以为其做出贡献并对加以改进。当 Facebook 将其发布到社区时,得到了大量的认同。...在本系列的下一篇教程中,我将深入研究 GraphQL,展示 GraphQL 如何与类型一起工作,并创建我们的第一个查询和修改。 所以请继续关注并希望在下一个教程中见到你!

    1.6K30

    GraphQL在现代Web应用中的应用与优势

    GraphQL是一种现代的API查询语言,它在现代Web应用中得到了广泛的应用,因为它提供了一种高效、灵活且强大的方式来获取数据GraphQL基础快速应用示例:1....查询根和突变根接下来,定义GraphQL的查询根(Query)和突变根(Mutation)类型,它们是客户端请求数据和修改数据的入口点。type Query { user(id: ID!)...Directives的理解和使用Directives是GraphQL schema中用于改变执行行为的指令。它们可以被应用到类型系统定义的任何部分,比如字段、输入类型、对象类型等。...错误处理自定义错误处理,提升客户端对错误的处理能力。...减少错误:客户端定义查询结构,服务器返回预期的形状,降低了由于接口不匹配导致的错误。更好的API设计:强类型系统确保了数据的一致性和正确性,使得API更加易于理解和维护。

    10710

    GraphQL两年实战避坑经验

    GraphQL 已得到广泛认可并日益流行。我们在使用中遇到了一些非常有挑战性的问题,值得撰文分享。本文将使用一个示例配置来阐释问题,并给出相应的解决方法。 ?...GraphQL Schema 每次更新时,都必须重新启动多个 API。这非常繁琐。 另一个可能出现的问题是,如果应用需要逆链反向查询,而非顺链而下查询,这时拼接无法工作。...Schema 包装是一个非常强大的方法,尤其是针对同一 API 种拼接了所有远程 Schema 的情况。详细信息,参见 Schema 包装的官方文档。...下面给出一些有助于构建可维护 GraphQL API 的小建议: 类型和枚举的命名必须唯一。...例如,如果需要对 Product 添加一个状态,建议命名为 ProductStatus,而不要直接使用 Status,以免出现类型冲突问题。 建议在查询中添加过滤,以免额外单独编写查询。

    1.1K30

    一杯茶的时间,上手 Gatsby 搭建个人博客

    但接下来还是会有一些小坑,第一个便是 GraphQL,我们将马上来分析。 为什么用 GraphQL 在上一节介绍了选择 Gatsby 的原因,其中提到了 Gatsby 使用 GraphQL 。...这里面查询语句虽然写的是字符串,但其实这些查询语句不会出现在最终的代码中,Gatsby 会先对其抽取[17]。 个人其实不太喜欢魔法,因为会增加初学者的理解难度。...我在修改 starter 时踩到一个坑是复制组件时忘了修改 static query 查询语句的名称,导致重名报错。 避免错误最好方式是在 GraphiQL 编辑器中写好运行无误再复制到组件中。...同时 MarkdownRemark 的集合对应为 allMarkdownRemark connections。...Gatsby 如何生成特定页面 一般来说,在 /src/pages/ 目录下的组件会自动生成相应路径的页面,但如果是其它类型的文件就不会了。

    3.2K20

    GraphQL 分享 理论篇

    有时候我们不需要的字段后台也给我们返回了,这是由后台控制的。 而GraphQL可以完美的解决上面的问题 GraphQL是…....Facebook 2012年开发,2015年开源 应用层的API查询语言 在服务端的运行数据查询语言的规范 (我建议你先抽半个小时浏览下心里有个大概) GraphQL的特点 强类型 单一入口 一个请求获取所有所需资源...使用GraphQL 注意的问题 性能问题 (请求少了,但查询多了) GraphQL 在前端如何与视图层、状态管理方案结合 安全, Limit, timeout N+1 查询 关于从规范里提炼的 GraphQL...注释只能用 # ,可以使用末尾的逗号提高可读性。 GraphQL的命名是大小写敏感的,也就是说name,Name,和NAME是不同的名字。 一个文档可以包含多个操作和片段的定义。...如果一个文档只有一个操作,那这个操作可以不带命名或者简写,省略掉query关键字和操作名。 下一篇 实战 参考: http://graphql.org/graphql-js/

    71030

    API架构风格对比:SOAP vs REST vs GraphQL vs RPC

    RESTful架构应该遵循以下六个架构约束: 统一接口:为一个给定的服务(无论是设备还是应用类型)提供统一的接口。...确实,HATEOAS是最成熟的REST版本,但很难实现比通常使用和构建的API客户端更加高级和智能的API客户端。因此,即使是如今非常好的REST API也不能保证面面俱到。...除RESTful CRUD操作外,GraphQL还有订阅功能,允许接收服务端的实时通知。 GraphQL 的优点 类型化的模式:GraphQL 会提前发布它可以做的事情,这种方式提升了可发现性。...详细的错误消息:与SOAP类似,GraphQL提供了详细的错误信息,错误信息包括所有的解析器以及特定的查询错误。 灵活的权限:GraphQL允许在暴露特定的功能的同时保留隐私信息。...REST具有高度抽象以及最佳的API模型。但往往会增加线路和聊天的负担--如果使用的是移动设备,这是不利的一面。

    3K11

    PayPal大规模采用GraphQL的探索和实践

    使用 GraphQL,我们可以获得字段级的检测,并清楚了解哪个解析器花了多长时间、常见错误以及调用了哪些字段。这个字段级检测有助于智能地弃用不再使用的字段。...使用联邦 GraphQL,所有团队共享同一个 schema,因此更容易识别重复项并使变量命名一致。...这些标准定义了命名约定、GraphQL 类型、请求头标准、指令标准和异常处理技术。 所有 GraphQL 操作都需要指定特殊指令,这些指令描述查询、突变和字段的所有授权要求。...当我们介绍 GraphQL 概念时,有时我们被告知 REST 也可以这样做。是的,它可以,我们也可以使用 REST 复制 GraphQL 所做的事情,但最后,我们只是在重新创建 GraphQL。...我们还没有得到所有前端或后端开发人员的完全认证,但是我们的 REST API 和 GraphQL API 可以共存。我们学会了不操之过急,一点点来。

    3.1K20

    GraphQL 基础实践

    什么是 GraphQL GraphQL 是一款由 Facebook 主导开发的数据查询和操作语言, 写过 SQL 查询的同学可以把它想象成是 SQL 查询语言,但 GraphQL 是给客户端查询数据用的...同样的,如果传出的 ratings 数据类型不为 String,也同样会抛出类型不符的错误。 列表(List)、枚举类型(Enum) ?...需要注意的是[Movie]!与 [Movie!]两种写法的含义是不同的:前者表示 movies字段始终返回不可为空但Movie元素可以为空。...后者表示movies中返回的 Movie 元素不能为空,但 movies字段的返回是可以为空的。 你可能在请求体中注意到,genre 参数的值没有被双引号括起来,也不是任何内置类型。...字段得到的是一组 id,不符合 Schema 的定义,此时 GraphQL 会抛出错误。

    12.8K20

    GraphQL是API的未来,但它并非银弹

    话虽如此,是什么阻碍了你运行两个版本的 GraphQL 模式?我不认为这是个好主意,但技术上是可行的。...但那时,GraphQL 可能也就不必要了。 3 降低有效载荷 在这一段中,作者指出,RESTful API 不允许部分响应。这是错误的。这里有一个例子: GET /users?...你将模式上传到模式注册中心,然后因为错误部署了 GraphQL 服务器的错误版本。如果你更改字段的类型,客户端可能就无所适从了。...无论使用哪种,你最终都会得到一个 GraphQL 模式,它描述了所有的类型和字段,并允许你对它们进行注释。 那么,有什么区别呢?OAS 设置开销更大。...GraphQL 的错误处理真的更好吗?我认为,OAS 和 GraphQL 都提供了不错的工具,让你可以用非常友好的方式处理错误。充分利用这些工具是开发人员的事。天下没有免费的午餐。

    2K10

    GraphQL 是一个陷阱?

    尽管有些 API 在设计上支持通用特性,但就像大多数 API 的风格一样,GraphQL API 是通用的还是特定的,是您自己决定的。...相比其它风格的 API,我没有发现使用 GraphQL 更难维护,实际上可以说它更容易维护,但这可能是有点自欺,因为很多 GraphQL 项目都是新领域,通常比累积了技术债务的遗留 API 具有更好的可维护性...在构建 GraphQL API 时,有很多方法可以进行改善,比如正确设置批处理和缓存数据加载;如果您将对象类型视为 “资源”或“端点”时,安全性与其它 API 都非常相似。...其实,我很好奇作者是怎么得到的结论,这通常不是 GraphQL 执行导致的查询。...这个主题可以作为提醒在构建 GraphQL API 时不要做什么,然而有些地方像稻草人一样,错误地描述了 GraphQL 构建的目的。

    1K10
    领券