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(Automatic persisted queries) 。
使用 GraphQL 构建 web 应用
+ $1 + $1 + $1 + $1 + [状态码]() + [N+1 Query 问题与 Dataloader]() - 待续 + [按需查询数据库字段]() - 待续 + [用户认证与 JWT]() - 待续 + [实现一个简单的 CRUD]() - 待续 + [graphql、cacheControl 与缓存]() - 待续 +