GraphQL 指南
共 10 篇
hello, world 示例
发布于我们先写一个关于 graphql.js 的 hello, world 示例,并且围绕它展开对 graphql 的学习 由上,也可以看出 graphql 很关键的两个要素: schema 和 query 。而当我们开发 web 应用时, schema 将会是服务端的主体,而 query 存在于前端中,类似 REST 中的 API。
源码分析
发布于更新于1. 验证 Schema 的有效性 1. 解析 Source(Operation) 1. 执行 + validateSchema + validateRootTypes + validateDirectives + validateTypes + parseSource + Source + Document + execute + ro
了解 graphql: schema 与 operation
发布于从上文 $1 中可以看出 graphql 很关键的两个要素: schema 和 operation 。 而当我们开发 web 应用时, schema 将会是服务端的主体,而 operation 存在于前端中,类似 REST 中的 API。 我们先抽出 schema 的代码部分,这里有 GraphQLSchema , GraphQLObje
graphql 与 http
发布于graphql 仅仅提供了 schema 与 operation/query 的用法,当我们在 web 中使用 graphql 时,就需要使用 HTTP 把 graphql 隔离为 client 与 server 两端。想象一个流程: 1. 前端发送 operation 到后端 1. 后端维护一个 schema 1. 后端根据前端的 op
resolve function
发布于再回到刚开始的 hello, world 的示例,用 graphql 表示如下 对以上章节的内容再梳理一遍: 1. 可以对 hello 进行查询,因为该字段在 Query 下 1. HELLO 查询所得到的 data.hello 是一个字符串 恩?我们好像把最重要的内容给漏了, hello 中的内容到底是什么?!而 resolve 函数就
client-cache
发布于+ network-only + store-and-network + store-or-network + store-only + 仅网络 + 网络优先 + 缓存优先 + 仅缓存
异常监控
发布于在一个后端服务设计中,异常捕获是必不可少需要考虑的因素 而当异常发生时,能够第一时间捕捉到并且能够获得足够的信息定位到问题至关重要 刚开始,先抛出两个问题 1. 在生产环境中后端连接的数据库挂了,是否能够第一时间收到通知并定位到问题,而非期待用户反馈 1. 在生产环境中有一条 API 出了问题,能否衡量该错误的紧急重要程度,并根据
结构化日志
发布于在一个健壮的项目中,日志是必不可少的。而格式化的日志更有助于我们快速检索日志,更快的找到性能瓶颈,更快的解决线上故障。 如果在 nodejs 环境中,推荐 $1 作为日志库 在所有关于日志的组件/函数库中都会有 level 的属性。它表示日志的紧急程度。一般会分为以下几个等级 + error : 线上第一时间需要解决的问题 + warn
利用 hash/query 键值对优化网络性能 (APQ)
发布于更新于Apollo Server 的 APQ:queryHashCache、带 sha256Hash 的 GET 请求示例,以及与缓存、Service Worker、CORS 的章节。
使用 GraphQL 构建 web 应用
发布于更新于+ $1 + $1 + $1 + $1 + 状态码 + N+1 Query 问题与 Dataloader - 待续 + 按需查询数据库字段 - 待续 + 用户认证与 JWT - 待续 + 实现一个简单的 CRUD - 待续 + graphql、cacheControl 与缓存 - 待续 +