Web应用在防火墙内部运行，它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行，通过较低带宽、较高延迟的互联网或移动网路访问。
在实践微服务系列博客的这一篇中，我们将看看如何使用GraphQL将Account对象提供给我们的客户端。
大家好，我叫储惠龙（实名上网），你可以叫我小龙人，00 后一枚。目前从事后端开发工作。
为了介绍使用ASP.NET Core构建GraphQL服务器，本文需要介绍一下GraphQL，其实看官网的文档就行。
过去几年中，GraphQL 已经成为一种非常流行的 API 规范，该规范专注于使客户端（无论是客户端、前端还是第三方）的数据获取更加容易。
GraphQL是Facebook的一个开源项目，定义了一种查询语言，用来代替传统的RESTful API。看到QL这样的字眼，很容易产生误解，以为是新的数据库查询语言，但其实GraphQL和数据库没有什么太大关系，GraphQL并不直接操作查询数据库，可以理解为传统的后端代码与数据库之间又多加了一层，这一层就是GraphQL.
GraphQL 是一种面向数据的 API 查询风格。传统的 API 拿到的是前后端约定好的数据格式，GraphQL 对 API 中的数据提供了一套易于理解的完整描述，客户端能够准确地获得它需要的数据，没有任何冗余，也让 API 更容易地随着时间推移而演进。
本文中，你会学到 GraphQL 类型系统的所有细节并且它是如何去描述什么样的数据是可以被查询的。既然 GraphQL 可以再任何后端框架和编程语言中使用，所以我们暂且不谈 GraphQL 的实现细节，只聚焦于核心概念。
举一个例子，例如现在有这么一个查询书籍信息的接口：/book/info，按照我们之前的解决方案，我们一般会传一个类似book_id的参数到这个接口，然后接口把书籍信息返回给我们
GraphQL 是用于客户端与服务器通信的语言规范。它有多种语言的实现，可以在广泛的环境中使用。https://graphql.org/code/
GraphQL 是 Facebook 开发的一种 API 的查询语言，与 2015 年公开发布，是 REST API 的替代品。
本文最初发布于 Max Desiatov 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。
GraphQL 可将 API 表示的数据通过解析函数映射到 GraphQL 的 schema 中，为 API 提供一套类型化的完整描述，使得客户端能够根据所需准确地获取相应数据。
随着多终端、多平台、多业务形态、多技术选型等各方面的发展，前后端的数据交互，日益复杂。
古映杰，携程研发高级经理，负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。
GraphQL 日渐成为数据查询的主流标准之一。每天都会产生许多围绕这项技术发展的精彩讨论和新工具。GraphQL最棒的特性就是提供了一个丰富语言集来描述获取数据的API。但是用户该如何描述这种查询语言，以及GraphQL这项核心技术本身呢？let's talk!
下面是GraphQL的定义： GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。
作者 | Anupama Pathirage 译者 | 明知山 策划 | 丁晓昀 在当今的数字转型时代，应用程序和 Web 服务之间的相互对话是不可避免的，我们需要通过 API 来实现这些应用程序之间的通信。各种协议和规范定义了消息通过网络传递的语义和语法，最终形成了一种 API 架构。 在本文中，我们将探讨如何使用 GraphQL 和 Ballerina 将 MySQL 数据库中的数据作为 API 公开出来。GraphQL 是一种抽象了底层数据源的规范，借助 GraphQL，开发人员能够灵活地使
本文首先介绍了 GraphQL，再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL，详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送，并附有使用示例，边用边学印象深刻~
GraphQL是一种新型的，令人兴奋的，用于特定查询和操作的API。它非常灵活并且有很多好处。 它特别适合以图形和树型为组织的数据。Facebook在2012年研发出了GraphQL并在2015年将其开源。
原英文： https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
本文第一部分翻译自REST 2.0 Is Here and Its Name Is GraphQL，标题很有视觉冲击力，不小心上钩了
接前面的文章，考虑这么一种场景，有时候我们希望根据某些参数条件来决定返回某些字段。比如下面的查询操作，有时候我们希望返回name字段，有时候不希望。
GraphQL 是由 Facebook 开发并开源的。提到 GraphQL ，大家自然而然会提起 RESTful api。下面对比一下 RESTful api 和 GraphQL 的优缺点。
今天最常讨论的术语之一是 API，很多人不知道 API 到底是什么，API 是 Application Programming Interface(应用程序编程接口)。顾名思义，它是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
很久之前其实就关注过这个技术，记得当时还是React刚刚崭露头角的时期吧。总之那时候，GraphQL感觉还只是概念完备阶段，除了FB自己内部大量使用外，好像社区并不是很健全，不过大家应该都在疯狂的讨论和跟进吧。过了2年，如今再回过头来看，已经涌现出各种开源或商用服务专注于这个领域，各种语言的框架和工具也都很完备了，感觉是时候重新接触GraphQL了。如果你的项目正处于技术选型，你正在犹豫选择一种接口风格的时刻，不妨了解一下这个神奇而强大的玩意儿~~
一般的 Web 开发都是使用 RESTful 风格进行API的开发，这种 RESTful 风格的 API 开发的一般流程是：
GraphQL是一种现代的API查询语言，它在现代Web应用中得到了广泛的应用，因为它提供了一种高效、灵活且强大的方式来获取数据
创建一个 Spring Bean，此处需要实现 GraphQLQueryResolver 接口，并在该类中自定义一个方法来映射 graphqls 文件中的查询。
编者按：本文作者奇舞团前端开发工程师何文力，同时也是 W3C CSS 工作组成员。
与 RESTful 设计不同，GraphQL 一般仅暴露出一个接口供使用，而具体一个请求中需要什么数据，数据怎么样组织完全由 API 的使用者（客户端）来指定。当然，哪些数据可以被查询，数据的类型是怎么样的，则是由服务端给定的。指定的方式就是传入一段关于想要的结果（或操作）的描述，服务端保证返回符合要求的结果或报错。
GraphQL 默认支持五种标量类型：Int，Float，String，Boolean 和 ID，可以满足大部分的使用场景，但有时候需要一些特殊的属性类型，此时我们就可以使用自定义标量类型来实现。下面看一下怎么通过自定义标量类型来实现一个 DateTime 类型。
在互联网和物联网高度发达的今天，似乎一切都可以连接起来，而彼此连接通讯的方式就是API，而对于API，有很多种方式进行数据的传输，今天我们就来说一说API通信的演变过程。
注意：GraphQL 是 api 的查询语言，而不是数据库。从这个意义上说，它是数据库无关的， 而且可以在使用 API 的任何环境中有效使用，我们可以理解为 GraphQL 是基于 API 之上的一 层封装，目的是为了更好，更灵活的适用于业务的需求变化
产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。
在上一篇文章RPC vs REST vs GraphQL中，对于这三者的优缺点进行了比较宏观的对比，而且我们也会发现，一般比较简单的项目其实并不需要GraphQL，但是我们仍然需要对新的技术有一定的了解和掌握，在新技术普及时才不会措手不及。
Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
在过去的将近半年的时间里，作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务，与更早出现的 SOAP 和 REST 相比，GraphQL 其实提供的是一套相对完善的查询语言，而不是类似 REST 的设计规范，所以需要语言的生态提供相应的框架支持，但是由于从它开源至今也只有两三年的时间，所以在使用的过程中，尤其是在微服务架构中实践时确实还会遇到很多问题。
自从 Web 开始迅猛发展，对程序员来说开发 API 是一项很艰巨的任务。我们开发 API 的方式必须随着时间的推移而发展，以便我们始终可以开发良好、直观且设计良好的API。
REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
作者 | Nitesh Kumar 译者 | 张卫滨 策划 | Tina API 对于组织来讲正变得越来越重要，但是，构建安全、可扩展的 API 并非易事。本文从执行环境、API 技术、安全性等角度出发，介绍了如何构建高效、可扩展的 API。 本文最初发表于 Salesforce 站点，经作者 Nitesh Kumar 授权，由 InfoQ 中文站翻译分享。 API 是一个重要的工具，允许合作伙伴、开发人员和其他应用消费我们提供的微服务，与之进行通信，并基于此构建各种各样的功能。 高质量的 AP
全文以后端开发视角写作，部分涉及到前端开发的介绍可能存在错误或者不准确，欢迎在评论区斧正
对应的 Java Bean 就不在这里赘述了，读者感兴趣的话可以自行查询小黑同学上传在 github 上的源码。
今天分享一些实用的BurpSuite插件实用技巧，帮助白帽子如何在竞争激烈的src挖掘中吃上一块肉。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
