Graphql

GraphQL 工具本文章，会列举一些好用的 GraphQL 工具，他们能够大大晋升你在开发中应用 GraphQL 的效率哦！ Prisma你能够这么了解，Prisma 是一个 ORM 的库，让你应用 GraphQL 查问时，能够应用对象的模式去查问，而不须要应用查问语句去查问，十分不便，而且 Prisma 还领有以下特点： Prisma 反对很多数据库，比方 Mysql、PostgreSQL、MariaDB 等数据库，当前还会反对更多对 Typescript、JavaScript、Go 都有十分好的反对内置了一些 CURD 的性能 RelayRelay 是一个 JavaScript 库，由 Facebook 开发，比拟多的用在 React 开发中，在 React 开发时，能够应用 Relay 去对 GraphQL 进行增删改查，十分不便。 Relay 具备三个模块： Compiler：编译器，负责剖析、验证、优化Runtime：GraphQL 的运行环境Relay/React：Relay 与 React 集成在一起 Apifox依据官网的介绍，Apifox 是这样的一款工具 集成了API 文档、API 调试、API Mock、API 自动化测试 API 一体化合作平台领有更先进的 API 设计/开发/测试工具Apifox = Postman + Swagger + Mock + JMeter我用了一圈下来，发现 Apifox 的性能的确很多 反对接口文档、在线接口文档分享反对本地 Mock、云端 Mock 性能反对 自动化测试，包含测试用例、测试套件性能反对中文显示，且收费应用反对可视化校验、可视化数据库连贯领有 IDEA 插件 Apifox Helper领有命令行工具 apifox-cli，能够应用命令行运行测试用例 ...

意识 GraphQL前段时间，GraphQL 呈现并掀起了一阵热潮。然而 GraphQL 跟 REST 是两种不同的货色，所以也须要肯定的学习老本，导致大部分人都没有抉择去学习它，明天就带大家简略过一遍 GraphQL 吧，心愿大家能有所播种。 常识扩大：GraphQL 和 REST 比照 GraphQL 好在哪？首先来说说 GraphQL 到底好在哪： GraphQL 速度快并且稳固GraphQL 能够获取更多的资源GraphQL 是单端点查问GraphQL 的可持续性十分杰出GraphQL 具备向下兼容的个性GraphQL 应用场景GraphQL 的按需查问十分实用，试想一下，你们在开发一个十分大型的网站的时候，一个首页就得申请很多个接口了，比方： 轮播图接口Tag 接口List 接口在下面的例子里，一个首页就得申请三个以上的接口了，浏览器并发数太多的话，会大大影响用户的应用体验。 那如果应用 GraphQL 去查问呢，就只须要一个接口就完事了，也就是一个申请就能够查问很多个申请所须要的数据，那天然缩小了并发数。 GraphQL 教程GraphQL 其实不难，无非就是传个不同的 query语句 到后端，接管不同的 JSON 罢了。 query 查问比方我当初要设计一个学生治理平台，我想查问学生列表，我应该传什么参数呢？ 剖析一下下面的语句： query：操作类型getStudents：操作函数名students：是后端定义好的接口id,name,age：指的是咱们须要查问的字段这样查问，返回的数据为： 察看下面的数据，使咱们想要的数据，并且只返回咱们须要查问的字段。 传参查问咱们刚刚说了 getStudents 是 函数名，那既然是函数，必定是能够传参的，比方，咱们只须要查问 id 为 1 的学生，咱们能够这么传： query variables 这样就能查到咱们想要的数据了。 mutation 批改后面讲的是 query 语句，咱们试一下 mutation 语句，他能够对数据进行批改、新增。 比方咱们想要新增一个学生，咱们能够这么写： 调试 GraphQL 接口步骤咱们写完 GraphQL 接口之后，咱们须要应用 API 工具对 GraphQL 接口进行调试。 ...

本周刊记录乏味好玩的独立产品设计开发相干内容，每周公布，往期内容同样精彩，感兴趣的搭档能够点击订阅我的周刊。为保障每期都能收到，倡议邮件订阅。欢送通过 Twitter 私信举荐或投稿。产品举荐1940s.nyc - 这个网站能够看到 90 年代纽约市的街景照片，太多照片了，根本齐全笼罩，还有另外一个我的项目是看 80 年代时候照片的。 Madsounds - 应用 Spotify 听歌的敌人们能够关上这个网站，受权登陆之后就会主动创立一个每日发现的歌单，关上 APP 就能够间接看到，相似 原本就有的每周新发现歌单，这个第三方的插件还是挺有意思的，第一次看到还有这种操作。 screen.studio - 这个屏幕录制软件做的很粗劣，鼠标点击动效，静止含糊，产品设计的很难看，交互也很不错，产品适宜用来录制完分享社交平台，例如Twitter 演示等场景，这个软件只实用于 macOS，反对 120FPS 的 4K 录制。89 美元买断制，一个许可证，容许最多三台设施装置和应用。 Letterloop - 这个产品能够给你的家人、敌人或者团队创立一个私密的 Newsletter，每个人都能提出和答复乏味的问题，用来分享本人的生存等，用来拉近家人和敌人之间的间隔，不得不说当初即时通信工具十分发达，信息过于爆炸，能用这种形式放弃短暂然而高效的社交形式还是很有创意的，能够看一下官网给出的一些应用案例。产品付费，每月 50 美元。 Paper Airplane Designs - 这个网站收集了很多纸飞机的设计，很乏味啊。 正则表达式游戏 - 这是个益智游戏，能够测试你写正则表达式的技能。 signlearner - 这是一个浏览器插件，用来学习手语，装置这个插件之后，会在你浏览的网站上随机呈现一些词语，悬浮下来就会呈现一个视频教这个词语的手语如何表白。做的很不错。小众然而有价值的产品。 开源我的项目Book Keeping - 九快记账是一款开源的记账类的工具软件，次要给集体和开店店主应用，反对手机和电脑，手机（包含安卓和iOS）通过装置APP应用，电脑通过浏览器应用。 ToastFish - 这是一个利用 Windows 告诉栏背单词的软件。能够让你在下班、上课等顽劣环境下平安荫蔽的背单词。能够查看背诵记录，能够将背诵记录导入，从新背诵，自定义 Excel 内容等性能。软件齐全开源且收费。 GitHub 推出两种新字体：Mona Sans 和 Hubot Sans - 来自 GitHub 的两种可变开源字体。 lenis - 这是一个前端框架，用来做平滑滚动成果，那些很丝滑的网页动效看上去就很业余。开源我的项目。 Slimicon - 这是一个收费开源的图标库。100多个圆角线形图标。 ...

本周刊记录乏味好玩的独立产品设计开发相干内容，每周公布，往期内容同样精彩，感兴趣的搭档能够点击订阅我的周刊。为保障每期都能收到，倡议邮件订阅。欢送通过 Twitter 私信举荐或投稿。产品举荐Manhole - 这个网站太有意思了，收录了十分多全世界各地乏味的井盖！还能看这个井盖具体在什么中央。第一次感觉井盖还能够有这么多的设计！另外强烈推荐看一下这个 Reddit 频道：r/manholeporn/。日本的井盖设计真多，又可恶又难看，另外这个网站还开发了 APP 能够上传你看到的乏味的井盖。 ezcv - 这是一个在线制作简历的网站，十分简洁好用，默认了一些罕用的排版，用最简略的款式展现你的简历内容。 TakeAscreen - 这是一个截图优化编辑的工具，浏览器插件，能够疾速应用标注，抉择款式等操作，还是很不便的。付费产品，价格不高。 Who is in space - 这个网站显示当初有多少人在太空，有多少个厕所在太空，有多少被动摸索其余星球的机器人。 The Deep Sea - 这个网站也很有意思，能够很直观地看海底多深的中央有什么用的生物。 Post-Secret Voicemail - 这个网站能够公布匿名的语音，下面有很多人的留言，很多都在讲述本人比拟悲伤的人生。 Flick Focus - 这个网站能够用来治理你观看电影电视剧等的数据，而且这个网站上找电影的体验比 IMDb 好用多了，能够查看乏味的统计数据，例如评分最高和观看次数最多的导演、演员、平均水平。评级公布年份及更多。这个网站应用 TMDb 的 API 开发。不能间接在下面看电影。另外举荐试试 Trakt.tv 治理你的观看数据。 Figma 主题切换插件 - 这是 @leadream4 开发的又一款优良的插件，感兴趣能够看看 视频介绍，能够试用 3 天，当初七折促销中。次要性能：增加本地或近程款式为主题，疾速切换主题，从一个主题复制款式生成新主题，分享主题给共事/敌人。这里购买。 开源我的项目hackers mind map - 适宜开发者用的思维导图工具，次要用键盘操作。太过于极客，普通用户就别用了。 轻易看看The Hustlers - 这个 Newsletter 次要整顿一些人的副业以及支出等等，曾经出了几期了，做的还不错。Starter Story - 这个 Newsletter 整顿了很多守业新我的项目，有 3806 个案例钻研，波及为数千名建设业务的创始人。一些适宜 SwiftUI 初学者的教程 - 对 SwiftUI 感兴趣的敌人能够看看。东坡肘子 @fatbobman 整顿的教程，针对技术根底较低的学习者（ 甚至能够零根底学习 ）。史蒂夫乔布斯档案 - Steve Jobs Archive 这个网站整顿了乔布斯的次要思维。Kalënder 2023 - 明年的日历曾经有人设计了，没记错的话当初曾经有余100天往年就完结了。这个能够收费下载而后打印，设计的还不错。 ...

The blockchain system consists of （Wey》StPv888）numerous nodes, which are similar to a Tai When a computer works independently, each node will participate in the competition when accounting is required. The system will select the most appropriate node for accounting within a period of time, and this node will record the recent data changes in the data block. After the recording is completed, the node will send this data block to other nodes. Other nodes will first verify the data. If the data is correct, This data block will also be put into its own account book, so all nodes in the system have exactly the same data block, that is, the account book. ...

本文介绍了 Apache APISIX 和 GraphQL 的个性，以及如何应用 API 网关 Apache APISIX 代理 GraphQL 申请，并提出解决理论场景痛点的计划。 背景信息GraphQL 是一个开源的、面向 API 而发明进去的数据查问操作语言以及相应的运行环境。最后由Facebook 于 2012 年外部开发，2015 年公开公布。2018 年 11 月 7 日，Facebook 将 GraphQL 我的项目转移到新成立的 GraphQL 基金会。 您能够把 GraphQL 类比为 SQL 查问语句来了解，与 SQL 查问语句相比，GraphQL 对 API 中的数据提供了一套易于了解的残缺形容，让客户端可能通过自定义的形容来精确取得其所须要的数据。这也让 API 可能从容面对日益简单的接口倒退，并防止最终成为一个令人望而却步的简单接口。 Apache APISIX 作为云原生网关，在设计之初就曾经具备辨认 GraphQL 语法的匹配能力。通过对申请中携带的 GraphQL 语句进行高效匹配，筛除异样流量，进一步保障安全性和进步零碎性能。 场景解析咱们正处于大数据大流量的时代，Apache APISIX 和 GraphQL 能够通过联合的形式，造成共赢的场面。接下来举一个场景具体阐明。 本文将会探讨微服务架构场景下的 Apache APISIX 和 GraphQL 的理论利用。 理论场景中遇到的问题在我的项目进行到前期时，往往会呈现业务复杂化、团队人员流动性低等问题，而微服务架构曾经成为解决这类问题的常见解决方案。在微服务架构中，GraphQL 暴露出的接口分为分散式和集中式两种，然而只有集中式接口设计才可能最大化体现 GraphQL 的劣势，然而在集中式接口设计中，所有的微服务对外裸露的是同一个接口，因而解决流量的路由就不能简略地依据 URL 进行转发，而是应该依据申请中蕴含的不同字段进行转发。 因为 NGINX 解决申请时仅会解决 URL 以及一些参数，然而只有解析申请参数中的查问信息才能够晓得客户端拜访的资源，从而进行路由转发，因而这种路由转发形式通过传统的 NGINX 是无奈实现的。在理论利用场景中，将 GraphQL 接口间接对外裸露十分危险，因而须要一个业余的高性能 API 网关爱护 GraphQL 的接口。 ...

不看废话版：err.networkError.result.errors（list） this.$apollo.mutate({ mutation: ***,//mutation name variables:{ *** // 一些参数 }}).then(res => { //接口200时解决，，，}).catch((err)=>{ if(err&& err.networkError&& err.networkError.result&&err.networkError.result.errors&&err.networkError.result.errors[0]){ let errors = err.networkError.result.errors[0]; let mes = errors.message; alert(mes)//或者其余解决 }})

【注】本文译自：GraphQL - Quick Guide (tutorialspoint.com)    在本章中，咱们将创立一个简略的 API，它返回一条问候音讯 HelloWorld，并应用 GraphiQL 拜访它。 示例    本示例基于 NodeJS、Express 和 Apollo 服务器。咱们将学习通过以下步骤将所有概念联合起来： 第 1 步：设置 Express    ExpressJS 是一个 Web 利用框架，可帮忙构建网站和 Web 应用程序。在这个例子中，咱们将在 Express 框架之上构建一个 GraphQL API。    下一步是创立文件夹 hello-world-server 并从终端导航到同一文件夹。增加 package.json，并为包命名。因为此包仅在外部应用，咱们能够将其申明为公有。 { "name": "hello-world-server", "private": true}    装置 Express 服务器的依赖项，如下所示：C:\Users\Admin\hello-world-server>npm install express body-parser cors    body-parser 是一个中间件包，能够帮忙 Express 无效地解决 HTTP Post 申请。cors 是另一个解决跨源资源共享的中间件包。    在我的项目文件夹中创立 server.js 文件并在其中键入以下内容： const bodyParser = require('body-parser')const cors = require('cors')const express = require('express')const port = process.env.PORT|| 9000const app = express()//register middlewareapp.use(bodyParser.json() , cors())app.listen(port, () => console.log(`server is up and running at ${port}`))    要验证 Express 服务器是否已启动并正在运行，请在终端窗口中执行以下代码：C:\Users\Admin\hello-world-server>node server.js    以下输入显示在服务器控制台中。这表明 express 服务器正在端口 9000 上运行。server is up and running at 9000    如果您关上浏览器并输出 http://localhost:9000 ，您将看到以下屏幕：    要进行服务器，请按 Ctrl + C。 ...

【注】本文译自： GraphQL - Quick Guide (tutorialspoint.com)    GraphQL 是形容 GraphQL 服务器行为的标准。它是一组对于如何解决申请和响应的指南，如反对的协定、服务器能够承受的数据格式、服务器返回的响应格局等。客户端向 GraphQL 收回的申请服务器称为查问。GraphQL 的另一个重要概念是其传输层不可知性。它能够与任何可用的网络协议一起应用，如 TCP、websocket 或任何其余传输层协定。它对数据库也是中立的，因而您能够将它与关系数据库或 NoSQL 数据库一起应用。    能够应用上面列出的三种办法中的任何一种来部署 GraphQL Server： 带有连贯数据库的 GraphQL 服务器集成现有零碎的 GraphQL 服务器混合办法 集成连贯数据库的 GraphQL 服务器    这种架构有一个带有集成数据库的 GraphQL 服务器，通常能够用于新我的项目。收到查问后，服务器读取申请无效负载并从数据库中获取数据。这称为解析查问。返回给客户端的响应遵循官网 GraphQL 标准中指定的格局。    在上图中，GraphQL 服务器和数据库集成在一个节点上。客户端（桌面/挪动）通过 HTTP 与 GraphQL 服务器通信。服务器解决申请，从数据库中获取数据并将其返回给客户端。 GraphQL 服务器集成现有零碎    这种办法对于领有遗留基础设施和不同 API 的公司很有帮忙。GraphQL 可用于对立现有零碎中的微服务、遗留基础设施和第三方 API。    在上图中，GraphQL API 充当客户端和现有零碎之间的接口。客户端应用程序与 GraphQL 服务器通信，后者反过来解析查问。 混合办法    最初，咱们能够将以上两种形式联合起来，搭建一个 GraphQL 服务器。在这种架构中，GraphQL 服务器将解析收到的任何申请。它将从连贯的数据库或集成的 API 中检索数据。这如下图所示：

【注】本文节译自：GraphQL - Quick Guide (tutorialspoint.com)    在本章中，咱们将学习 GraphQL 的环境设置。 要执行本教程中的示例，您将须要以下内容： 运行 Linux、macOS 或 Windows 的计算机。网络浏览器，最好是最新版本的 Google Chrome。装置了最新版本的 Node.js。倡议应用最新的 LTS 版本。已装置实用于 VSCode 的扩大 GraphQL 的 Visual Studio Code 或您抉择的任何代码编辑器。如何应用 Nodejs 构建 GraphQL 服务器    咱们将具体介绍应用 Nodejs 构建 GraphQL 服务器的步骤，如下所示： 第 1 步 - 验证节点和 Npm 版本    装置 NodeJs 后，在终端上应用以下命令验证 node 和 npm 的版本： C:\Users\Admin>node -vv8.11.3C:\Users\Admin>npm -v5.6.0第 2 步 - 创立我的项目文件夹并在 VSCode 中关上 我的项目的根文件夹能够命名为 test-app。    依照以下阐明应用 Visual Studio 代码编辑器关上文件夹： C:\Users\Admin>mkdir test-appC:\Users\Admin>cd test-appC:\Users\Admin\test-app>code.第 3 步 - 创立 package.json 并装置依赖项    创立 package.json 文件，该文件将蕴含 GraphQL 服务器应用程序的所有依赖项。 ...

【注】本文节译自：GraphQL - Quick Guide (tutorialspoint.com)     GraphQL 是 Facebook 开发的一种开源服务器端技术，用于优化 RESTful API 调用。它是一种执行引擎和一种数据查询语言。在本章中，咱们将探讨应用 GraphQL 的劣势。 为什么应用 GraphQL    RESTful API 遵循清晰且构造良好的面向资源的办法。然而，当数据变得更简单时，路由会变得更长。有时无奈通过单个申请获取数据。这就是 GraphQL 派上用场的中央。GraphQL 以图的模式构建数据，其弱小的查问语法用于遍历、检索和批改数据。    以下是应用 GraphQL 查询语言的劣势： 询问你想要的 - 并失去它    向您的 API 发送 GraphQL 查问并精确获取您须要的内容。GraphQL 查问总是返回可预测的后果。应用 GraphQL 的应用程序且稳固。与 Restful 服务不同，这些应用程序能够限度应该从服务器获取的数据。     以下示例将帮忙您更好地了解这一点：    让咱们思考一个具备属性 id、firstName、lastName 和 CollegeName 的业务对象 Student。假如一个挪动利用只须要获取 firstName 和 id。 如果咱们设计一个像 /api/v1/students 这样的 REST 端点，它最终会为一个 Student 对象的所有字段获取数据。这意味着，数据被 RESTful 服务适度获取。 这个问题能够通过应用 GraphQL 来解决。    思考上面给出的 GraphQL 查问： { { id firstName }}    这将仅返回 id 和 firstname 字段的值。该查问不会获取学生对象的其余属性的值。下面阐明的查问的响应如下所示： { "data": { "students": [ { "id": "S1001", "firstName": "Mohtashim" }, { "id": "S1002", "firstName": "Kannan" } ] }}在单个申请中获取多个资源    GraphQL 查问有助于顺利检索关联的业务对象，而典型的 REST API 须要从多个 URL 加载。GraphQL API 在单个申请中获取您的应用程序所需的所有数据。即便在迟缓的挪动网络连接上，应用 GraphQL 的应用程序也能够很快。    让咱们再思考一个业务对象 College，它具备以下属性：名称和地位。 Student 业务对象与 College 对象具备关联关系。如果咱们应用 REST API 来获取学生及其大学的详细信息，咱们最终将向服务器收回两个申请，如 /api/v1/students 和 /api/v1/colleges。这将导致每个申请的数据获取有余。 因而，挪动利用被迫屡次调用服务器以获取所需的数据。     然而，挪动利用能够应用 GraphQL 在单个申请中获取 Student 和 College 对象的详细信息。    以下是用于获取数据的 GraphQL 查问： ...

**大题目一文理解近期Filecoin网络最新动静！**Linden灵动 明天 收录于话题 Filecoin网络2IPFS分布式存储3业余专一 共建共赢 9月1日，Filecoin全网无效算力冲破10EiB，迈入里程碑新阶段！ 除了算力方面的惊人成就，Filecoin网络近期还产生了哪些小事？上面一起回顾一下吧 1 创立 DoraHacks Filecoin Grant黑客松闭幕 2021年DoraHacks Filecoin Grant黑客松投票环节拉下帷幕。该较量自5月1日继续进行至7月中旬，在获奖我的项目前三甲中共发放了约24.9万美元的处分。这些获奖我的项目将帮忙构建Filecoin网络将来。 公布Filecoin-Polygon Bridge Filecoin发表与Polygon单干，以减速两个生态之间的Web3互操作性。这项单干始于Textile团队近期创立的Filecoin-Polygon Bridge。 为进一步激励开发人员在桥上进行尝试和构建，Filecoin和Polygon为任何应用Textile Bridge的我的项目提供收费存储。单方还安顿了两场行将启动的联结黑客松，开发人员能够在此尝试搭建桥梁并构建新的应用程序。（点击此处理解单干详情） 02 存储 JigStack Gallery推动IPFS和Filecoin一体化 Gallery是JigstackDAO的最新解决方案，是一个由$STAK治理和激励的多个DeFi产品治理平台。Gallery是Jigstack进入NFT生态系统的入口，为NFT和STAK持有者发明新鲜和创意性的机会。 Gallery发表，他们将应用IPFS和Filecoin存储NFT，这也是他们行将官宣的打算中不可或缺的一部分。 为Mask Network提供去中心化存储 Mask Network和Filecoin发表单干，拟通过向Mask用户提供去中心化存储计划来桥接Web2和Web3。 Mask Network是连贯Web2平台和Web3准则的当先协定。Mask browser extension容许任何人在Facebook和Twitter等传统平台上与别人互动，但需应用Web3准则和解决方案。用户能够通过Gitcoin发送和接管加密音讯、转移加密货币或参加赞助我的项目，并且很快就能够通过Filecoin网络存储和共享文件。 通过Mask browser extension，用户可能抉择将特定文件上传至Filecoin网络，并将其作为加密或未加密的资产共享至他们的网络中。 Web3.Storage在The New Stack中的性能 The New Stack对Web3.Storage相当认同，且于近期推出了为开发人员提供收费拜访（实在且无限期）Filecoin网络的存储解决方案。 Web3.storage带来了冗余度和繁难应用形式，向更多的资深或老手Web3开发人员关上了通往去中心化存储世界的大门。 03 存储提供者 Filecoin社区批准扭转存储提供者术语 8月20日，通过数周征求整个Filecoin社区对Filecoin改良提案18 (FIP-0018)的意见和反馈后，Filecoin社区批准了FIP-0018，更改了存储市场及其存储提供者的命名约定。 此命名约定将在Filecoin文档网站、Githhub、Filecoin和Filecoin基金会官网社交媒体渠道以及其余生态工具中全面更新。 Lotus公布v 1.11.1版本 Lotus v1.11.1版本现已上线。此版本在交易和数据存储方面做出很多改良，并减少了新个性和bug修复。 Proofs公布v9.0.0&v9.0.1版本 Proofs v9.0.0&v9.0.1版本现已上线，并在lotus v1.11.2rc系列中标记，以供测试。这些版本将默认的bls381库从配对转换为blst，因为其通过审计和测量后在性能方面更胜一筹。 鉴于存储提供者在一段时间内根本都将blst作为可选性能，因而将其作为默认个性有其价值所在。这个版本还让外部线程库实现从rayon切换到yastl的转变，以改善并行工作负载中的调度。 04 ...

深刻GraphQL 的应用语法对于GraphQL 的应用语法在上一节中曾经大略介绍了根本的应用形式了，这一篇将会对上一篇入门做拓展，致力将所有的应用语法都笼罩到。 1. 终端语法首先是介绍在前端查问时用的语法，分成Query 和Mutation 两局部，Subscription 的和Query 是相似的就不特地阐明了。 1.1 Query假如咱们当初有一个数据集，构造是这样的： 学生和老师各有各自的特有字段；学生中有个获取所有相干老师的办法，老师中也有一个获取所有学生的办法；学生和老师互为多对多关系；classDiagram Student <|-- Teacher2Student Teacher <|-- Teacher2Student class Student { +Int id +String name +Int age +teachers(id_eq: number) get_all_teachers } class Teacher { +Int id +String name +Boolean gender +students(name_contains: string) get_all_students } class Teacher2Student { +Int id +Int student_id +Int teacher_id +student() get_student +teacher() get_teacher }首先最简略的应用形式咱们可查： query { student { id name teacher { id name } }}# 后果：{ data: { student: [ { id: 1, name: "张三", teacher: [ { id: 1, name: "李老师" }, { id: 2, name: "吴老师" } ] }, { id: 2, name: "李四", teacher: [ { id: 1, name: "李老师" } ] }, { id: 3, name: "王三", teacher: [ { id: 2, name: "吴老师" } ] } ] }}咱们通过下面的查问能够失去总共有两个学生，其中李老师同时教了他们两人。这是最最根本的用法。上面咱们缓缓加查问需要去扭转后果。 ...

GraphQL 概念入门Restful is Great! But GraphQL is Better. -- My Humble Opinion. GraphQL will do to REST what JSON did to XML. -- Samer Buna from Quora GraphQL 作为 Facebook 的前端三架马车之一（另外两架是 Relay 和 React, 三者能够无缝联合），提出也有一段时间了，但真正用过的人却出奇的少，截止到 2018 年底，依据 Stateofjs 的数据看，尽管只有 1/5 的开发人员用过，但却有高达 62.5% 的人示意听过并想试试 果然咸鱼才是支流呀；接下来我会就 GraphQL 的前后端利用出个系列文章介绍 GraphQL 及其应用感触，顺便填坑。 本系列将以 Python + Django + Graphene 作为后端服务端。Apollo 作为前端客户端。 1. 什么是 GraphQL官网是这么说的： GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查问的运行时。 GraphQL 对你的 API 中的数据提供了一套易于了解的残缺形容，使得客户端可能精确地取得它须要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建弱小的开发者工具。我总结一下： ...

本文由智能化研发管理工具PingCode技术经理 龚林杰分享什么是 GraphQLA query language for your APIs GraphQL 是一种由 Facebook 提出的用于 API 的查询语言，也是一个满足你数据查问的运行时。 GraphQL 对你的 API 中的数据提供了一套易于了解的残缺形容，使得客户端可能精确地取得它须要的数据，而且没有任何冗余 罕用的API有哪些什么是APIAPI 全称：Application programming interface， API的实质就是读数据、写数据。 咱们罕用的API分成两个流派基于REST（Representational State Transfer）REST：体现层状态转移，是一种软件架构格调，而不是一个规范。REST 用 HTTP 封装，走的是 HTTP 协定。那么给予 REST 有哪些衍生品？RESTFUL: 操作资源 ，GraphQL: A query language for your APIs 基于RPC用自定义的协定 http, http2, 音讯队列(redis), tcp 等封装的一套近程调用的API，很典型的一个技术就是gRPC. 为什么要应用GraphQLREST API 存在的问题以及怎么应答POST / PUT / DELETE 傻傻分不清楚，有时候界线含糊因为是操作资源路由有时候会很长，如 /work-items/:id/comments/:cid/like数据返回冗余，叫 Overfetching数据返回短少一些字段，叫 Underfetching接口数据如何兼容不同平台咱们在应用REST接口时，接口返回的数据格式、数据类型都是后端事后定义好的，如果返回的数据格式并不是调用者所冀望的，作为前端的咱们能够通过以下两种形式来解决问题： 和后端沟通，改接口（更改数据源）本人做一些适配工作（解决数据源）后端专门为其余平台(挪动端)提供接口GraphQL 的劣势在哪借助 GraphQL，组织内的不同客户端应用程序能够轻松地仅查问所需数据，这一点超过了其它 REST 办法，并带来了理论应用程序性能的进步。应用传统的 REST API 端点，客户端应用程序将详询服务器资源，并承受蕴含了与申请匹配的所有数据的响应。如果来自 REST API 端点的胜利响应返回 35 个字段，那么客户端应用程序就会收到 35 个字段。 ...

GraphQL是Facebook提出的一种数据查询语言，外围个性是数据聚合和按需索取，目前被广泛应用于前后端之间，解决客户端灵便应用数据问题。本文介绍的是GraphQL的另一种实际，咱们将GraphQL下沉至后端BFF层之下，联合元数据技术，实现数据和加工逻辑的按需查问和执行。这样不仅解决了后端BFF层灵便应用数据的问题，这些字段加工逻辑还能够间接复用，大幅度晋升了研发的效率。本文介绍的实际计划曾经在美团局部业务场景中落地，并获得不错成果，心愿这些教训可能对大家有帮忙。1 BFF的由来BFF一词来自Sam Newman的一篇博文《Pattern:Backends For Frontends》，指的是服务于前端的后端。BFF是解决什么问题的呢？据原文形容，随着挪动互联网的衰亡，原适应于桌面Web的服务端性能心愿同时提供给挪动App应用，而在这个过程中存在这样的问题： 挪动App和桌面Web在UI局部存在差别。挪动App波及不同的端，不仅有iOS、还有Android，这些不同端的UI之间存在差别。原有后端性能和桌面Web UI之间曾经存在了较大的耦合。因为端的差异性存在，服务端的性能要针对端的差别进行适配和裁剪，而服务端的业务性能自身是绝对繁多的，这就产生了一个矛盾——服务端的繁多业务性能和端的差异性诉求之间的矛盾。那么这个问题怎么解决呢？这也是文章的副标题所形容的"Single-purpose Edge Services for UIs and external parties"，引入BFF，由BFF来针对多端差别做适配，这也是目前业界宽泛应用的一种模式。 在理论业务的实际中，导致这种端差异性的起因有很多，有技术的起因，也有业务的起因。比方，用户的客户端是Android还是iOS，是大屏还是小屏，是什么版本。再比方，业务属于哪个行业，产品状态是什么，性能投放在什么场景，面向的用户群体是谁等等。这些因素都会带来面向端的性能逻辑的差异性。 在这个问题上，笔者所在团队负责的商品展现业务有肯定的发言权，同样的商品业务，在C端的展现性能逻辑，粗浅受到商品类型、所在行业、交易状态、投放场合、面向群体等因素的影响。同时，面向消费者端的性能频繁迭代的属性，更是加剧并深入了这种矛盾，使其演化成了一种服务端繁多稳固与端的差别灵便之间的矛盾，这也是商品展现（商品展现BFF）业务零碎存在的偶然性起因。本文次要在美团到店商品展现场景的背景下，介绍面临的一些问题及解决思路。 2 BFF背景下的外围矛盾BFF这层的引入是解决服务端繁多稳固与端的差别灵便诉求之间的矛盾，这个矛盾并不是不存在，而是转移了。由原来后端和前端之间的矛盾转移成了BFF和前端之间的矛盾。笔者所在团队的次要工作，就是和这种矛盾作奋斗。上面以具体的业务场景为例，联合以后的业务特点，阐明在BFF的生产模式下，咱们所面临的具体问题。下图是两个不同行业的团购货架展现模块，这两个模块咱们认为是两个商品的展现场景，它们是两套独立定义的产品逻辑，并且会各自迭代。 在业务倒退初期，这样的场景不多。BFF层零碎“烟囱式”建设，性能疾速开发上线满足业务的诉求，在这样的状况下，这种矛盾体现的不显著。而随着业务倒退，行业的开辟，造成了许许多多这样的商品展现性能，矛盾逐步加剧，次要体现在以下两个方面： 业务撑持效率：随着商品展现场景变得越来越多，API呈爆炸趋势，业务撑持效率和人力成线性关系，零碎能力难以撑持业务场景的规模化拓展。零碎复杂度高：外围性能继续迭代，外部逻辑充斥着if…else…，代码过程式编写，零碎复杂度较高，难以批改和保护。那么这些问题是怎么产生的呢？这要联合“烟囱式”零碎建设的背景和商品展现场景所面临的业务，以及零碎特点来进行了解。 特点一：内部依赖多、场景间取数存在差别、用户体验要求高 图例展现了两个不同行业的团购货架模块，这样一个看似不大的模块，后端在BFF层要调用20个以上的上游服务能力把数据拿全，这是其一。在下面两个不同的场景中，须要的数据源汇合存在差别，而且这种差别普遍存在，这是其二，比方足疗团购货架须要的某个数据源，在丽人团购货架上不须要，丽人团购货架须要的某个数据源，足疗团购货架不须要。只管依赖上游服务多，同时还要保障C端的用户体验，这是其三。 这几个特点给技术带来了不小的难题：1）聚合大小难管制，聚合性能是分场景建设？还是对立建设？如果分场景建设，必然存在不同场景反复编写相似聚合逻辑的问题。如果对立建设，那么一个大而全的数据聚合中必然会存在有效的调用。2）聚合逻辑的复杂性管制问题，在这么多的数据源的状况下，不仅要思考业务逻辑怎么写，还要思考异步调用的编排，在代码复杂度未能良好管制的状况下，后续聚合的变更批改将会是一个难题。 特点二：展现逻辑多、场景之间存在差别，共性共性逻辑耦合 咱们能够显著地辨认某一类场景的逻辑是存在共性的，比方团单相干的展现场景。直观能够看出基本上都是展现团单维度的信息，但这只是表象。实际上在模块的生成过程中存在诸多的差别，比方以下两种差别： 字段拼接逻辑差别：比方以上图中两个团购货架的团购题目为例，同样是题目，在丽人团购货架中的展现规定是：[类型] + 团购题目，而在足疗团购货架的展现规定是：团购题目。排序过滤逻辑差别：比方同样是团单列表，A场景依照销量倒排序，B场景依照价格排序，不同场景的排序逻辑不同。诸如此类的展现逻辑的差异性还有很多。相似的场景实际上在外部存在很多差别的逻辑，后端如何应答这种差异性是一个难题，上面是最常见的一种写法，通过读取具体的条件字段来做判断实现逻辑路由，如下所示： if(category == "丽人") { title = "[" + category + "]" + productTitle;} else if (category == "足疗") { title = productTitle；}这种计划在性能实现方面没有问题，也可能复用独特的逻辑。然而实际上在场景十分多的状况下，将会有十分多的差异性判断逻辑叠加在一起，性能始终会被继续迭代的状况下，能够设想，零碎将会变得越来越简单，越来越难以批改和保护。 总结：在BFF这层，不同商品展现场景存在差别。在业务倒退初期，零碎通过独立建设的形式反对业务疾速试错，在这种状况下，业务差异性带来的问题不显著。而随着业务的一直倒退，须要搭建及经营的场景越来越多，呈规模化趋势。此时，业务对技术效率提出了更高的要求。在这种场景多、场景间存在差别的背景下，如何满足场景拓展效率同时可能控制系统的复杂性，就是咱们业务场景中面临的外围问题。 3 BFF利用模式分析目前业界针对此类的解决方案次要有两种模式，一种是后端BFF模式，另一种是前端BFF模式。 3.1 后端BFF模式后端BFF模式指的是BFF由后端同学负责，这种模式目前最宽泛的实际是基于GraphQL搭建的后端BFF计划，具体是：后端将展现字段封装成展现服务，通过GraphQL编排之后裸露给前端应用。如下图所示： 这种模式最大的个性和劣势是，当展现字段曾经存在的状况下，后端不须要关怀前端差异性需要，按需查问的能力由GraphQL反对。这个个性能够很好地应答不同场景存在展现字段差异性这个问题，前端间接基于GraphQL按需查问数据即可，后端不须要变更。同时，借助GraphQL的编排和聚合查问能力，后端能够将逻辑合成在不同的展现服务中，因而在肯定水平上可能化解BFF这层的复杂性。 然而基于这种模式，依然存在几个问题：展现服务颗粒度问题、数据图划分问题以及字段扩散问题，下图是基于以后模式的具体案例： 1）展现服务颗粒度设计问题 这种计划要求展现逻辑和取数逻辑封装在一个模块中，造成一个展现服务（Presentation Service），如上图所示。而实际上展现逻辑和取数逻辑是多对多的关系，还是以前文提到的例子阐明： 背景：有两个展现服务，别离封装了商品题目和商品标签的查问能力。情景：此时PM提了一个需要，心愿商品在某个场景的题目以“[类型]+商品题目”的模式展现，此时商品题目的拼接依赖类型数据，而此时类型数据商品标签展现服务中曾经调用了。问题：商品题目展现服务本人调用类型数据还是将两个展现服务合并到一起？以上形容的问题的是展现服务颗粒度把控的问题，咱们能够狐疑上述的示例是不是因为展现服务的颗粒度过小？那么反过来看一看，如果将两个服务合并到一起，那么势必又会存在冗余。这是展现服务设计的难点，外围起因在于，展现逻辑和取数逻辑自身是多对多的关系，后果却被设计放在了一起。 2）数据图划分问题 通过GraphQL将多个展现服务的数据聚合到一张图（GraphQL Schema）中，造成一个数据视图，须要数据的时候只有数据在图中，就能够基于Query按需查问。那么问题来了，这个图应该怎么组织？是一张图还是多张图？图过大的话，势必带来简单的数据关系保护问题，图过小则将会升高计划自身的价值。 3）展现服务外部复杂性 + 模型扩散问题 ...

依据后面的学习，能够发现 GraphQL 带来了很多便当和翻新。具备以下几个次要的劣势： 1、缩小数据冗余和申请冗余，能够更获取和应用数据；2、灵便而强类型的 schema，GraphQL 是强类型的，他能够帮忙开发者防止很多问题；3、因为强类型的应用，GraphQL 能够自动化地对收到的数据进行测验；4、GraphQL 不须要进行接口文档保护，它能主动生成，加之其自省性能，能够说很不便；5、进步开发效率，缩小代码变更次数，长期保护老本升高；只管 GraphQL 有很多劣势，但万物并不是完满的，其也有如下的毛病，正是这些导致其没有被大规模应用： 1、成熟的解决方案比拟少，引入 GraphQL 老本略高，危险也不小，这就很大水平上限度了受众；2、减轻前后端利用比重,前端会带一个 graphql-client，缩短用户等待时间；3、GraphQL 产生大量冗余查问，尽管网络层面的申请数被优化了，但GraphQL的每一个实体背地可能对应着不同的数据库甚至不同类型的存储集群，后端集群间的海量数据查问便会成为性能瓶颈。绝对于resetful,有显著的降性能的状况；4、GraphQL 的利好次要是在于前端的开发效率，但落地却须要服务端的全力配合，对于曾经成熟的公司技术栈，要推动 GraphQL 还是会遇到各种合作上的阻力；5、谬误提醒不敌对,REST API的状况下，咱们不须要解析Response的内容，只须要看HTTP status code和message，就能晓得申请是否胜利，大略问题是什么，处理错误的程序也非常容易编写。然而GraphQL只有Service自身还在失常运行，咱们就会失去200的HTTP status，须要专门查看response的内容才晓得是否有error，这时须要全局中间件解决 http error code 到graph-error的映射；总结GraphQL 最大的劣势，就是它可能大大提高开发者的效率，而且最大化地简化了前端的数据层的复杂性，使得前后端对数据的组织观点统一。但咱们抉择一项技术时，须要考查其 scale、performance、tech stack、migration等多方面的因素，否则它可能不仅没能提高效率和性能，反倒制作出更多的问题。

文章原文请移步我的博客：GraphQL 接口设计 graphql 是一种用于 API 的查询语言。它提供了一套残缺的和易于了解的 API 接口数据形容，给客户端势力去精准查问他们须要的数据，而不必再去实现其余更多的代码，使 API 接口开发变得更简略高效。 最近在用Gatsby开发一版动态博客，感觉和这个框架真是相见恨晚。因为这个框架应用到了graphql技术，所以我花了点工夫去学习了一下，并且记录了一下学习和思考过程。 本文次要解说如何了解graphql以及基于关系型数据库设计graphql的思路。如果须要学习graphql基础知识，请移步官网文档 本文蕴含Nestjs + graphql的示例我的项目：https://github.com/YES-Lee/nestjs-graphql-starter 了解graphqlgraphql是一个用于形容数据及其关系的查询语言，官网文档中形容了graphql的规范，具体的实现依附第三方，目前支流的是Apollo提供的解决方案。 graphql并不关怀具体咱们是怎么获取数据的，咱们只须要提供获取数据的办法（resolver）以及如何组装数据（schema）。相似于Java开发过程中的接口设计模式，Graphql定义了一套规范，咱们依照规范实现接口。上面以用户-角色模型举例。 上面的代码定义了两个数据结构，与JSON相似，应该很容易了解。它形容了每个类型（type）的名称，以及其蕴含的属性。属性除了能够是根本类型外，也能够是数组、其余援用类型，从而建设起所有数据模型及互相的关系图。 type Role { name: String note: String}type User { id: Int name: String gender: Int role: Role}下面代码用于形容Role和User的数据结构，那么咱们具体要怎么应用这个货色呢？先从前端的角度来看，能够从官网文档学习到前端的根本应用，申请体中的数据形容和下面定义类型的代码有些许差异，比方咱们要查问用户数据： query userInfo { user(id: Int) { id name gender role { name note } }}从下面的代码能够大略猜测出，如果咱们不须要查问role数据是，只须要将其从申请中去掉 query userInfo { user(id: Int) { id name gender }}当申请达到服务端时，graphql会对申请体进行解析，当解析到user时，会执行咱们定义好的获取user数据的逻辑，解析到role也是同样的情理。那么咱们得在服务端定义好获取数据的逻辑，在graphql中叫做resolver。 之前的代码只定义了数据的构造，咱们还须要为其创立一个resolver来获取对应的数据，相似于上面的代码 function userResolver (id) { // ... // return User}function roleResolver (userId) { // ... // return Role}咱们能够在resolver中执行sql、http申请、rpc通信等任何可能获取到所需数据的逻辑。最终只须要依照预约义的构造将数据返回即可。 ...

欢送浏览 ???? 本文会通过理论场景介绍一下 GraphQL，目标是让你疾速理解 GraphQL 是什么，以及根本工作思路，不蕴含理论用法，所以浏览很轻松。 一、GraphQL 是什么？GraphQL 是后端数据查询语言，能够简略了解为 GraphQL 对标的是 REST 接口。 GraphQL 由 Facebook 开源，目前曾经在 Facebook 中撑持千亿级的 API 接口调用，在 Facebook 之外正在被迅速利用。 咱们不要被 GraphQL 这个名字误导了，第一次看见它时，我还认为这是一个图数据库的查询语言呢。 GraphQL 大体上确实是 "图查问" 的意思，但这个 "图" 是数据图谱的意思，不是图数据库。 二、GraphQL 思路 以上图为例，这是支流的 Feed 流模式，如何实现呢？ 定下来界面中须要显示哪些数据元素之后，后端开始为其定制一个 REST 接口，查问出相干数据： Post 帖子作者Like 喜爱Comment 评论Share 分享后端程序员进行数据关联查问，取出其中须要的数据项，而后封装为一个易于前端操作的数据结构，例如 JSON 对象。 这样 Feed 流的接口就 OK 了，同样的，对于其余界面再进行相应的接口开发。 例如在帖子详情页面，波及的数据还是 Feed 流中的这些，但具体的数据项不同了，例如： 帖子须要全文Like 须要点赞用户的图像列表、IDComment 评论须要详情列表因为数据项的不同，就须要针对这个界面需要从新开发吧。 如果你嫌麻烦，提供了一个大而全的接口，后端开发是简略了，但新问题来了，例如： 前端开发须要从后果数据中认真挑出本人所须要的数据项。接口返回数据中蕴含大量的前端无用数据，会占用更多的带宽，影响性能，例如 Facebook 那种千亿级的 API 调用量，这种带宽的节约是不能容忍的。有什么更好的方法呢？（如果你有更好的教训，欢送发给我，我会分享给大家） Facebook 为了解决这个问题，设计出了 GraphQL。 ...

原文：https://blog.heroku.com作者：CHRIS CASTLE微信搜寻【前端全栈开发者】关注这个脱发、摆摊、卖货、继续学习的程序员，第一工夫浏览最新文章，会优先两天发表新文章。关注即可大礼包，准能为你节俭不少钱！ 在过来的几年中，GraphQL曾经成为一种十分风行的API标准，该标准专一于使客户端（无论客户端是前端还是第三方）的数据获取更加容易。 在传统的基于REST的API办法中，客户端发出请求，而服务器决定响应： curl https://api.heroku.space/users/1{ "id": 1, "name": "Luke", "email": "luke@heroku.space", "addresses": [ { "street": "1234 Rodeo Drive", "city": "Los Angeles", "country": "USA" } ]}然而，在GraphQL中，客户端能够准确地确定其从服务器获取的数据。例如，客户端可能只须要用户名和电子邮件，而不须要任何地址信息： curl -X POST https://api.heroku.space/graphql -d 'query { user(id: 1) { name email }}{ "data": { "name": "Luke", "email": "luke@heroku.space" }}通过这种新的模式，客户能够通过缩减响应来满足他们的需要，从而向服务器进行更高效的查问。对于单页利用(SPA)或其余前端重度客户端利用，能够通过缩小有效载荷大小来放慢渲染工夫。然而，与任何框架或语言一样，GraphQL也须要衡量取舍。在本文中，咱们将探讨应用GraphQL作为API的查询语言的利弊，以及如何开始构建实现。 为什么抉择GraphQL？与任何技术决策一样，理解GraphQL为你的我的项目提供了哪些劣势是很重要的，而不是简略地因为它是一个风行词而抉择它。 思考一个应用API连贯到近程数据库的SaaS应用程序。你想要出现用户的个人资料页面，你可能须要进行一次API GET 调用，以获取无关用户的信息，例如用户名或电子邮件。而后，你可能须要进行另一个API调用以获取无关地址的信息，该信息存储在另一个表中。随着应用程序的倒退，因为其构建形式的起因，你可能须要持续对不同地位进行更多的API调用。尽管每一个API调用都能够异步实现，但你也必须解决它们的响应，无论是谬误、网络超时，甚至暂停页面渲染，直到收到所有数据。如上所述，这些响应的有效载荷可能超过了渲染你以后页面的须要，而且每个API调用都有网络提早，总的提早加起来可能很可观。 应用GraphQL，你无需进行多个API调用（例如 GET /user/:id 和 GET /user/:id/addresses ），而是进行一次API调用并将查问提交到单个端点： query { user(id: 1) { name email addresses { street city country } }}而后，GraphQL仅提供一个端点来查问所需的所有域逻辑。如果你的应用程序一直增长，你会发现自己在你的架构中增加了更多的数据存储——PostgreSQL可能是存储用户信息的好中央，而Redis可能是存储其余品种信息的好中央——对GraphQL端点的一次调用将解决所有这些不同的地位，并以他们所申请的数据响应客户端。 ...

作者：CHRIS CASTLE原文：https://blog.heroku.com译者：杜尼卜微信搜寻【前端全栈开发者】关注这个脱发、摆摊、卖货、继续学习的程序员的公众号，第一工夫浏览最新文章，会优先两天发表新文章。关注即可大礼包，送某网精品视频课程网盘材料，准能为你节俭不少钱！ 在过来的几年中，GraphQL曾经成为一种十分风行的API标准，该标准专一于使客户端（无论客户端是前端还是第三方）的数据获取更加容易。 在传统的基于REST的API办法中，客户端发出请求，而服务器决定响应： curl https://api.heroku.space/users/1{ "id": 1, "name": "Luke", "email": "luke@heroku.space", "addresses": [ { "street": "1234 Rodeo Drive", "city": "Los Angeles", "country": "USA" } ]}然而，在GraphQL中，客户端能够准确地确定其从服务器获取的数据。例如，客户端可能只须要用户名和电子邮件，而不须要任何地址信息： curl -X POST https://api.heroku.space/graphql -d 'query { user(id: 1) { name email }}{ "data": { "name": "Luke", "email": "luke@heroku.space" }}通过这种新的模式，客户能够通过缩减响应来满足他们的需要，从而向服务器进行更高效的查问。对于单页利用(SPA)或其余前端重度客户端利用，能够通过缩小有效载荷大小来放慢渲染工夫。然而，与任何框架或语言一样，GraphQL也须要衡量取舍。在本文中，咱们将探讨应用GraphQL作为API的查询语言的利弊，以及如何开始构建实现。 为什么抉择GraphQL？ 与任何技术决策一样，理解GraphQL为你的我的项目提供了哪些劣势是很重要的，而不是简略地因为它是一个风行词而抉择它。 思考一个应用API连贯到近程数据库的SaaS应用程序。你想要出现用户的个人资料页面，你可能须要进行一次API GET 调用，以获取无关用户的信息，例如用户名或电子邮件。而后，你可能须要进行另一个API调用以获取无关地址的信息，该信息存储在另一个表中。随着应用程序的倒退，因为其构建形式的起因，你可能须要持续对不同地位进行更多的API调用。尽管每一个API调用都能够异步实现，但你也必须解决它们的响应，无论是谬误、网络超时，甚至暂停页面渲染，直到收到所有数据。如上所述，这些响应的有效载荷可能超过了渲染你以后页面的须要，而且每个API调用都有网络提早，总的提早加起来可能很可观。 应用GraphQL，你无需进行多个API调用（例如 GET /user/:id 和 GET /user/:id/addresses ），而是进行一次API调用并将查问提交到单个端点： query { user(id: 1) { name email addresses { street city country } }}而后，GraphQL仅提供一个端点来查问所需的所有域逻辑。如果你的应用程序一直增长，你会发现自己在你的架构中增加了更多的数据存储——PostgreSQL可能是存储用户信息的好中央，而Redis可能是存储其余品种信息的好中央——对GraphQL端点的一次调用将解决所有这些不同的地位，并以他们所申请的数据响应客户端。 ...

第二部分：了解解析器 在第一部分中，我们开发了一个非常简单的GraphQL服务器。该解决方案有一个严重的缺陷：所有字段都急切地加载到后端，即使前端未要求也是如此。通过不给客户任何选择，我们通过RESTful服务来接受这种情况。RESTful API始终返回所有内容，这意味着始终加载所有内容。另一方面，如果将RESTful API分为多个较小的资源，则可能会面临N + 1问题和多次网络往返的风险。GraphQL是专门为解决以下问题而设计的： 仅获取必需的数据，以避免额外的网络流量以及后端不必要的工作允许在单个请求中获取客户端所需的尽可能多的数据，以减少总体延迟RESTful API可以任意决定要返回多少数据，因此几乎无法解决上述问题。它要么获取过多，要么获取不足。好的，这是理论，但是我们对GraphQL服务器的实现不能以这种方式工作。无论是否请求，它仍将获取所有数据。伤心。 不断发展您的API要回顾一下我们的API返回一个实例PlayerDTO： @Valueclass Player { UUID id; String name; int points; ImmutableList<Item> inventory; Billing billing;}与此GraphQL模式匹配的： type Player { id: String! name: String! points: Int! inventory: [Item!]! billing: Billing!}通过仔细地分析我们的应用程序，我意识到很少有客户billing在他们的查询中提出要求，但是我们必须始终提出要求billingRepository才能创建Player实例。许多急切的，不需要的工作： private final BillingRepository billingRepository;private final InventoryClient inventoryClient;private final PlayerMetadata playerMetadata;private final PointsCalculator pointsCalculator;//...@NotNullprivate Player somePlayer() { UUID playerId = UUID.randomUUID(); return new Player( playerId, playerMetadata.lookupName(playerId), pointsCalculator.pointsOf(playerId), inventoryClient.loadInventory(playerId), billingRepository.forUser(playerId) );}像这样的字段billing只能在请求时加载！为了了解如何使我们的对象的某些部分_图_（Graph-QL是也）懒加载，让我们添加一个名为新特性trustworthiness到Player上： type Player { id: String! name: String! points: Int! inventory: [Item!]! billing: Billing! trustworthiness: Float!}此更改是向后兼容的。事实上，GraphQL实际上没有API版本控制的概念。那么迁移路径是什么？有以下几种情况： ...

广告Vue.js小书已经出版，尤小右作序推荐：http://www.ituring.com.cn/boo...欢迎购买。Swift iOS 小书 http://www.ituring.com.cn/boo... 正文GraphQL 原来2012年就已经开源，算来也有不少历史了，但是看起来网络资料并不太多，大家普遍还是觉得麻烦。单单看官方手册好像就太不亲人的，太容易从自己的角度去描述细节，而不是从使用的角度去剖析，这也是官方手册普遍的问题。 比如“获取多个资源，只用一个请求”，官方说： GraphQL 查询不仅能够获得资源的属性，还能沿着资源间引用进一步查询。典型的 REST API 请求多个资源时得载入多个 URL，而 GraphQL 可以通过一次请求就获取你应用所需的所有数据。这样一来，即使是比较慢的移动网络连接下，使用 GraphQL 的应用也能表现得足够迅速。因为他假设你知道REST API，并且和它对比。其实，认识一个新事物，认识它本身会更直接，认识清楚了，想要对比了再去对比才有价值。但是人们太喜欢使用类别了。 我曾经写过一个高点击率的文章，讲述了vuex是什么，因为大家普遍反映官方文档不好懂，原因是是它上来和reactive那套东西对比。作者这样做可以理解，因为他就是对比着做的，说出来的也是对比的话，也认为这是干货。但是读者就不太好了解，因为我vue还没有搞利索，现在你让我搞搞reactive才能动vue的东西。这很令人绝望。 我们还是从一个案例开始。假设我有两个数据实体，一个是book，一个是author，且book和author是1:对多的关系。它的数据样本，看起来是这样的： var books = [ {id:0,title:"null book",author:{name:"reco"}}, {id:1,title:"the little prince",author:{name:"reco"}}, {id:2,title:"the http book",author:{name:"reco"}}]var authors = [ {id:1,name:"reco",books:[{title:"the little prince"},{title:"the http book"}]}, {id:2,name:"rita",books:[{title:"the swift book"}]}]就是这样的数据源。如果使用Graphql来做查询，可以查询作者列表，且对作者对书籍的引用做进一步查询，也就是希望这样的查询： {authors{name,books{title}}}可以返回： { "data": { "authors": [ { "name": "reco", "books": [ { "title": "the little prince" }, { "title": "the http book" } ] }, { "name": "rita", "books": [ { "title": "the swift book" } ] } ] }}对author.name的查询，就是获取对象属性，是比较容易的，而对而对关联对象的延伸查询，其实和属性一模一样，只不过看起来是嵌套的而已。明确了目标，我们把代码跑起来，也还是typeDefs+resolvers的一套东西： ...