GraphQL 是由 Facebook 开发并开源的。提到 GraphQL ，大家自然而然会提起 RESTful api。下面对比一下 RESTful api 和 GraphQL 的优缺点。
Graphql 是一种查询语言、一个执行引擎和一个规范，它引导开发人员重新思考如何构建客户端和 API 应用程序
GraphQL是一种查询语言、一种执行引擎和一种规范，它引领开发人员重新思考应该怎样去构建客户端和API。
GraphQL 是一种面向数据的 API 查询风格。传统的 API 拿到的是前后端约定好的数据格式，GraphQL 对 API 中的数据提供了一套易于理解的完整描述，客户端能够准确地获得它需要的数据，没有任何冗余，也让 API 更容易地随着时间推移而演进。
过去几年中，GraphQL 已经成为一种非常流行的 API 规范，该规范专注于使客户端（无论是客户端、前端还是第三方）的数据获取更加容易。
我们通过构建收银台体验开启了我们的 GraphQL 采用之旅。当 我们用 GraphQL 构建收银台应用程序 时，我们看到了采用 GraphQL 的巨大好处，这成为我们的指路明灯。我们构建了更多的应用程序，提供了基础设施支持，发布了一个公共 GraphQL API，并在全公司提供了培训和学习材料。我们还建立了一个标准机构，提供了一个 GraphQL 工具 fanny pack，并构建了示例应用程序来帮助团队开始使用 GraphQL。
本文最初发布于 Max Desiatov 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。
在实践微服务系列博客的这一篇中，我们将看看如何使用GraphQL将Account对象提供给我们的客户端。
原英文： https://blog.apollographql.com/securing-your-graphql-api-from-malicious-queries-16130a324a6b
在这个数字时代，我们的日常生活中充斥着各种应用程序和系统之间的交互。无论是社交媒体、在线购物还是智能家居设备，它们都需要通过API（应用程序接口）来实现数据的传输和通信。然而，这些看似简单的操作背后隐藏着复杂的协议。
即使与 REST API 打交道这么多年，当我第一次了解到 GraphQL 和它试图解决的问题时，我还是禁不住把本文的标题发在了 Twitter 上。
本文首先介绍了 GraphQL，再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL，详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送，并附有使用示例，边用边学印象深刻~
在过去的将近半年的时间里，作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务，与更早出现的 SOAP 和 REST 相比，GraphQL 其实提供的是一套相对完善的查询语言，而不是类似 REST 的设计规范，所以需要语言的生态提供相应的框架支持，但是由于从它开源至今也只有两三年的时间，所以在使用的过程中，尤其是在微服务架构中实践时确实还会遇到很多问题。
作者 | Khalil Stemmler 策划 | 田晓旭 在服务器上使用 GraphQL 代替 REST 是有很多好处的，使用 Apollo Client 取代自己编写的数据获取逻辑也有很多优势。在这篇文章中，我们主要讨论 GraphQL 最突出的架构优势。 本文最初发布于 khalilstemmler.com 网站，经原作者授权由 InfoQ 中文站翻译并分享。 在过去的几年中，我们已经看到各种规模和形态的公司都开始在整个组织中逐渐采用 GraphQL，例如 Expedia、Nerdwallet 和 A
Web应用在防火墙内部运行，它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行，通过较低带宽、较高延迟的互联网或移动网路访问。
随着多终端、多平台、多业务形态、多技术选型等各方面的发展，前后端的数据交互，日益复杂。
作者 | 杜艮魁 审校 | 蔡芳芳 GraphQL 查询出的基础数据和业务需求往往有些差异，需要研发同学加工后才能渲染展示。而通过硬编码的方式对数据进行加工处理无法满足应用快速开发的需求，也与 GraphQL 配置化的思想相悖。本文将介绍如何通过指令和表达式实现 GraphQL 查询的计算能力，以减少代码开发和服务发版上线，提高业务迭代效率。 背 景 计算需求概述 GraphQL 作为接口描述语言，可对其治理的数据进行便捷的查询，但真实业务场景除了获取基础数据外，往往还需要对数据进行加工处理，概括如
GraphQL 可将 API 表示的数据通过解析函数映射到 GraphQL 的 schema 中，为 API 提供一套类型化的完整描述，使得客户端能够根据所需准确地获取相应数据。
本文讨论了四种主要的 API 架构风格，比较它们的优缺点，并重点介绍每种情况下最适合的 API 架构风格。
两个单独的应用程序需要中介程序才能相互通信。因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。
古映杰，携程研发高级经理，负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。
内容来源：2018 年 6 月 9 日，国内某大型电商公司用户体验部门前端开发专家邓若奇在“杭州第一届 GraphQLParty—GraphQL与领域驱动带来的协同价值”进行《基于SPA架构的GraphQL工程实践》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。
编者按：本文作者奇舞团前端开发工程师何文力，同时也是 W3C CSS 工作组成员。
Coursera 的客户端开发人员钟情于 GraphQL 的灵活性，类型安全性和良好的社区支持，我们对 GraphQL 的喜爱众~所~周~知。然而，我们并没有过多讨论后端开发人员是如何看待 GraphQL 的，因为他们大多数实际上并不需要考虑 GraphQL。
先简单对比以下GraphQL和WebAPI: GraphQL和Web API（如RESTful API）是用于构建和提供Web服务的不同技术。
最近，GraphQL 在构建后端 API 方面获得越来越多大公司的青睐， 如 PayPal、Facebook、Hasura、去哪儿等公司都做了大量实践。
作者 | Nitesh Kumar 译者 | 张卫滨 策划 | Tina API 对于组织来讲正变得越来越重要，但是，构建安全、可扩展的 API 并非易事。本文从执行环境、API 技术、安全性等角度出发，介绍了如何构建高效、可扩展的 API。 本文最初发表于 Salesforce 站点，经作者 Nitesh Kumar 授权，由 InfoQ 中文站翻译分享。 API 是一个重要的工具，允许合作伙伴、开发人员和其他应用消费我们提供的微服务，与之进行通信，并基于此构建各种各样的功能。 高质量的 AP
在API安全威胁不断加剧、多样化，数字化系统面临着巨大的安全挑战背景下，企业必须积极构建API安全能力。而企业API安全防护的首要任务是API资产进行清晰了解和有效管理。本期，我们将揭示API资产识别的关键技术，以帮助企业高效清晰地完成API资产梳理工作。
架构师的主要活动是做出正确的技术决策。选择合适的API是一项重要的技术决策。那么今天就看看API的选择问题。
微服务架构是一种将应用程序构建为一组小服务的方法，每个服务运行在其自己的进程中，并通过轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务能力构建，可以独立部署，由完全自治的团队维护。在我们深入构建微服务的过程之前，了解 GraphQL 在此架构中的作用非常重要。
GraphQL 日渐成为数据查询的主流标准之一。每天都会产生许多围绕这项技术发展的精彩讨论和新工具。GraphQL最棒的特性就是提供了一个丰富语言集来描述获取数据的API。但是用户该如何描述这种查询语言，以及GraphQL这项核心技术本身呢？let's talk!
我认为，GraphQL 将改变世界。将来，你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢？我个人最讨厌的是，社区一直在宣传 GraphQL 的好处，而这些好处却非常普通，并且与 GraphQL 实际上没有任何关系。如果我们想推广采用，那么我们应该诚实，应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础，因为它代表了我在社区中经常听到的观点。如果你读了整篇文章，当然这会花一些时间，你就会完全理解，为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
以太坊在去年升级的go-ethereum（geth）1.9.0大版本，除了性能得到大幅提升之外，引入了GraphQL，一种节点接口查询机制，用以补充JSON-RPC。
大概率你听说过 GraphQL，知道它是一种与 Rest API 架构属于 API 接口的查询语言。但大概率你也与我一样没有尝试过 GraphQL。
GraphQL 这个名词已经火了一段时间，但是一直没有体验过，无意中发现了一篇使用体验的文章，就想着翻译下分享给大家，如果翻译有问题的，还望批评指正。译文出自：掘金翻译计划[1]
REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。
作为 Facebook 在 2015 年推出的查询语言，GraphQL 能够对 API 中的数据提供一套易于理解的完整描述，使得客户端能够更加准确的获得它需要的数据
Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
本文比较了标准 API 和服务，以通过 Internet 查询数据以进行分析、集成和数据管理。
微服务架构，这个在几年前还算比较前卫的技术在如今遍地开花。得益于开源社区的支持，我们可以轻松地利用 Spring Cloud 以及 Docker 容器化快速搭建一个微服务架构的原型。不管是成熟的互联网公司、创业公司还是个人开发者，对于微服务架构的接纳程度都相当高，微服务架构的广泛应用也自然促进了技术本身更好的发展以及更多的实践。本文将结合项目实践，剖析在微服务的背景下，如何通过前后端分离的方式开发移动应用。 对于微服务本身，我们可以参考 Martin Fowler 对 Microservice 的阐述。简单
作者 | Anupama Pathirage 译者 | 明知山 策划 | 丁晓昀 在当今的数字转型时代，应用程序和 Web 服务之间的相互对话是不可避免的，我们需要通过 API 来实现这些应用程序之间的通信。各种协议和规范定义了消息通过网络传递的语义和语法，最终形成了一种 API 架构。 在本文中，我们将探讨如何使用 GraphQL 和 Ballerina 将 MySQL 数据库中的数据作为 API 公开出来。GraphQL 是一种抽象了底层数据源的规范，借助 GraphQL，开发人员能够灵活地使
「前端同学请求两个接口，聚合一下数据不就行了？」后端同学希望只提供业务领域基础 API 服务能力，数据组装处理则希望由前端同学完成。
无论是创建网站，还是移动应用程序，我们都需要通过 API 来传递数据，通过 API 我们可以获取到数据库中的数据，可以操作数据库，可以处理一些业务逻辑。现在最流行的 API 架构是 REST。但是，GraphQL 正在逐渐追赶着它。
此文是作者考虑 GraphQL 在 Node.js 架构中的落地方案后所得。从最初考虑可以（以内置中间件）加入基础服务并提供完整的构建、发布、监控支持，到最终选择不改动基础服务以提供独立包适配，不限制实现技术选型，交由业务团队自由选择的轻量方式落地。中间经历了解除误解，对收益疑惑，对最初定位疑惑，最终完成利弊权衡的过程。
正如我之前所写， GraphQL是下一代API技术，它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。
GraphQL介绍&使用nestjs构建GraphQL查询服务（文章底部附demo地址） GraphQL一种用为你 API 而生的查询语言。出自于Facebook，GraphQL非常易懂，直接看查询语
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
