前端调用 GraphQL API，从未如此方便！

[houfeng]

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余。

想更多的了解或使用 GraphQL，请移步 https://github.com/facebook/graphql

GraphQL 有针对不同语言的服务端实现，以帮助开发人员搭建 GraphQL Server。

而 gq-loader 是一个 webpack 插件，你可以认为它一针对前端项目的一种 client 端实现，它的目的是帮助前端开发同学更简便的调用 GraphQL API，它让前端开发人员在使用 GraphQL 时更加方便，像普通 js 模块一样轻松自如，使前端开发人员能在 js 文件中通过 import 或 require 导入 .gql 和 .graphql 文件，然后直接调用。 并且它还支持通过 #import 语法导入其它 .gql 文件，比如 fragments。

#import 还提供了两个别名，分别是 #require 和 #include，这两个别名和 #import 的用法及行为完全一致。

关注或使用 gq-loader，请访问 GitHub： https://github.com/Houfeng/gq-loader

安装

npm install gq-loader --save-dev

或者

yarn add gq-loader

基本使用

如同其它 loader 一样，首先，我们在 webpack.config.js 中添加 gq-loader 的配置

{
  test: /\.(graphql|gql)$/,
  exclude: /node_modules/,
  use: {
    loader: 'gq-loader'
    options: {
      url: 'Graphql Server URL'
    }
  }
}

然后，我们就可以在 js 文件中通过 import 来导入 .gql 文件使用它了，我们来一个简单的示例，假设已经有一个可以工作的 Graphql Server，那么，我们先创建一个可以查询用户的 getUser.gql

#import './fragment.gql' 

query MyQuery($name: String) {
  getUser(name: $name)
    ...userFields
  }
}

可以看到，我们通过 #import 引用了另外一个 .gql 文件 fragment.gql，在这个文件中我们描术了要返回的 user 的字段信息，这样我们就能在不同的地方「重用」它了，我们也创建一下这个文件

fragment userFields on User {
  name
  age
}

好了，我们可以在 js 文件中直接导入 getUser.gql，并且使用它查询用户了，从未如此简便，我们来看看

import getUser from './getUser.gql';
import React from 'react';
import ReactDOM from 'react-dom';

async function query() {
  const user = await getUser({ name: 'bob' });
  console.log('user', user);
}

function App() {
  return <button onClick={query}>click</button>;
}

ReactDOM.render(<App />, document.getElementById('root'));

在调用 getUser 时，我们可以给函数参数向 GraphQL 传递变量，这些变量就是我们的查询参数。

自定义请求

默认 gq-loader 就会帮你完成 graphql 请求，但某些场景下或许你想自已控制所有请求，如果有这样需要，我们还可以通过 request 属性来「自定义」请求，看一下示例，需要先稍微改动一下 loader 配置

{
  test: /\.(graphql|gql)$/,
  exclude: /node_modules/,
  use: {
    loader: 'gq-loader'
    options: {
      url: 'Graphql Server URL',
      //指定自动请求模块路径
      request: require.resolve('your_request_module_path');
    }
  }
}

在 your_request_module_path 填写自定义请求模块路径，gq-loader 将自动加载并使用对应请求模块，模块只需要改出一个「请求函数即可」，看如下自定义示例

const $ = require('jquery');

//url 是要请求的 GraphQL 服务地址
//data 是待发送的数据
//options 是自定义选项
module.exports = function(url, data, options){
  //如果有需要还可以处理 options
  return $.post(url, data);
};

其中，options 是导入 .gql 文件后「函数的第二个参数」，比如，可以这样传递 options 参数

import getUser from './getUser.gql';

async function query() {
  const options = {...};
  const user = await getUser({ name: 'bob' }, options);
  console.log('user', user);
}

完整选项

• url：指定 graphql 服务 URL，默认值为 /graphql
• request：自定义请求函数，默认值为「使用内建模块」
• extensions：默认扩展名，在导入时省略扩展名时将按配置依次查找，默认值为 .gql/.graphql，
• string：指定导入模式，当为 true 时导入的为字符串，而不是可执行的函数

注意，gq-loader 的 extensions 无论配置何值，在 js 中 import 时都不能省略扩展名，此选项仅作用于 .gql 文件 import 其它 .gql 文件

[xwhxbg]

除非前后端都是我，不然不可能用 graphql

[66beta]

@xwhxbg 此话怎讲？打一架也不能解决吗？

[xwhxbg]

@66beta 学习成本在那里，再怎么好用你没法强迫别人用，除非你是老板

[Sivan]

用不用是一回事，学一学没坏处 :P

[artikle]

用过 GraphQL 写后台接口,要注意的是它并非用来提升接口性能，相反反而会降低接口性能。
比如你一个完整响应有 10 个字段，你只要返回两个字段，后台不会只查询那两个字段，
而是先查询出完整响应，再逐字段遍历解析才返回所需的两个字段的值。
这个就导致完整响应的字段过多或者响应结果值过多都会导致接口性能下降明显。

[glues]

没看出 GraphQL 好在哪？

[tinyhill]

@Sivan 四万老师说得对

[coraline]

http://mirror.am0200.com/ 这个就是用 GitHub 的 GraphQL API 的

[EPr2hh6LADQWqRVH]

稍微通读了一下 Github 页面，看不出这个 GraphQL 哪里 Graph 了，不知道 FB 这个什么想法，是需要把全世界的东西都削足适履塞到 js 里面来吗，然后再把 js 世界的所有东西都塞到 php 思维里面

正经看一下 Neo4j 的 Cypher 吧，那才叫 Graph Query

[takato]

@avastms Cypher 好用+1

[torbrowserbridge]

用了一段时间，又滚回 MySQL 了

[tamer]

@glues don't you recognize me, brother

[artikle]

@glues GraphQL 还是有其优点的。
一个是它只返回所请求的字段信息。
比如一个用户信息响应有多个字段，但前端只需要 UserID 和 UserName，那接口能只返回 UserID 和 UserName 这两个响应字段,而不返回其他多余的响应字段，这个对于 facebook 这种每天接口请求几十几百亿次的话，减少的流量带宽还是比较可观的。
二是可以合并多个请求接口。比如后台有产品信息及产品详情页信息两个接口，在一个 GraphQL 接口里，可以同时返回产品信息和产品详情两个接口的响应结果

[glues]

@tamer 发英文？我看你这是在故意刁难我胖虎

[kslr]

@artikle #13 仅仅这两点，其他 database 也很轻松做到。我觉得重要的还是脱离了 API 吧，但是应用范围感觉不是太大。

[artikle]

@kslr 其他 database 也很轻松做到?怎么实现？

[kslr]

@artikle #16 你忘了 sql 吗？

[artikle]

@kslr sql ？难道前端传 sql 语句过来？

[mcfog]

和 https://www.apollographql.com/docs/react/recipes/webpack.html 的异同？

[kslr]

@artikle #18 restful 方案有很多啊....... GraphQL 没有诞生的时候就在用了

[artikle]

@kslr 。。。这个是不一样的东西。要实现前端控制只返回所查询的数据，比较好的是微软 oData 和 facebook 的 GraphQL，没见过其他比较好的方案。

[notreami]

谁敢用，我开除谁，没啥，我就是老板。。

[TommyLemon]

@artikle 这种做法性能不是一般的差啊，用 APIJSON 吧，自动将前端传的 JSON 转为 SQL 语句执行后返回对应结构的 JSON。前端可通过 @column:"id,name" 指定 SELECT id,name，只查需要的字段。右上角点 Star 支持下吧^_^
https://github.com/TommyLemon/APIJSON

[TommyLemon]

完爆 Facebook/GraphQL，APIJSON 全方位对比解析(一)-基础功能
https://juejin.im/post/5ae80edd51882567277433cf

完爆 Facebook/GraphQL，APIJSON 全方位对比解析(二)-权限控制
https://juejin.im/post/5b13cda1f265da6e4a6bcfee

[TommyLemon]

@xwhxbg @glues @avastms @kslr @notreami

用 APIJSON 吧，协议基于广泛使用的 JSON，学习和迁移成本都很低。
自动将前端传的 JSON 参数转为 SQL 语句执行并返回结果，
期间自动校验权限、结构、内容，自动防 SQL 注入。

通过自动化 API，前端可以定制任何数据、任何结构！
大部分 HTTP 请求后端再也不用写接口了，更不用写文档了！
前端再也不用和后端沟通接口或文档问题了！再也不会被文档各种错误坑了！
后端再也不用为了兼容旧接口写新版接口和文档了！再也不会被前端随时随地没完没了地烦了！

在线解析
自动生成文档，清晰可读永远最新
自动生成请求代码，支持 Android 和 iOS
自动生成 JavaBean 文件，一键下载
自动管理与测试接口用例，一键共享
自动校验与格式化 JSON，支持高亮和收展

对于前端
不用再向后端催接口、求文档
数据和结构完全定制，要啥有啥
看请求知结果，所求即所得
可一次获取任何数据、任何结构
能去除重复数据，节省流量提高速度

对于后端
提供通用接口，大部分 API 不用再写
自动生成文档，不用再编写和维护
自动校验权限、自动管理版本、自动防 SQL 注入
开放 API 无需划分版本，始终保持兼容
支持增删改查、模糊搜索、正则匹配、远程函数等

后端接口和文档自动化，前端(客户端) 定制返回 JSON 的数据和结构！
创作不易，GitHub 右上角点 Star 支持下吧，谢谢^_^
https://github.com/TommyLemon/APIJSON

[TommyLemon]

完爆 Facebook/GraphQL，APIJSON 全方位对比解析(三)-表关联查询
https://juejin.im/entry/5b4ff88f6fb9a04f914a8df5

[glues]

@TommyLemon 别动不动就完爆，你这玩意和 GraphQL 根本就不是一个水平层次的东西

[TommyLemon]

@glues
你说反了，从基础功能、易用性、数据结构灵活性、权限控制、接口安全性、接口工具等方面来讲，GraphQL 和 APIJSON 不是一个水平层次的东西。
3 篇博客都用了大量的真实依据来证明，你有什么依据也拿出来，或者文中说错的地方也欢迎指正，谢谢。
https://juejin.im/post/5ae80edd51882567277433cf

[xcstream]

php 是最好的语言，php 可以 html 和 sql 混着写，比 graphql 不知道高到哪里去了。