在过去的将近半年的时间里，作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务，与更早出现的 SOAP 和 REST 相比，GraphQL 其实提供的是一套相对完善的查询语言，而不是类似 REST 的设计规范，所以需要语言的生态提供相应的框架支持，但是由于从它开源至今也只有两三年的时间，所以在使用的过程中，尤其是在微服务架构中实践时确实还会遇到很多问题。
GraphQL是Facebook提出的一种数据查询语言，核心特性是数据聚合和按需索取，目前被广泛应用于前后端之间，解决客户端灵活使用数据问题。本文介绍的是GraphQL的另一种实践，我们将GraphQL下沉至后端BFF（Backend For Frontend）层之下，结合元数据技术，实现数据和加工逻辑的按需查询和执行。这样不仅解决了后端BFF层灵活使用数据的问题，这些字段加工逻辑还可以直接复用，大幅度提升了研发的效率。
随着多终端、多平台、多业务形态、多技术选型等各方面的发展，前后端的数据交互，日益复杂。
古映杰，携程研发高级经理，负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。
先回到会议的主题，为什么会开这么一个会议？原本这个会议报名的时候希望可以控制到 100 人之内，不要超过 120 人，结果报到 250 人还爆满了，后来没有办法，我们只能从工作经验来筛选，选择工作经验在三年以上的比较资深的工程师，和一部分 2 年经验工作经验的，还有 5 年的，10 年甚至更久的从业者。
作者简介 工业聚，携程高级前端开发专家，react-lite, react-imvc, farrow 等开源项目作者。 兰迪咚，携程高级前端开发专家，对开发框架及前端性能优化有浓厚兴趣。 一、前言 过去两三年，携程度假前端团队一直在实践基于 GraphQL/Node.js 的 BFF (Backend for Frontend) 方案，在度假BU多端产品线中广泛落地。最终该方案不仅有效支撑前端团队面向多端开发 BFF 服务的需要，而且逐步承担更多功能，特别在性能优化等方面带来显著优势。 我们观察到有些前端
BFF一词来自Sam Newman的一篇博文《Pattern:Backends For Frontends》，指的是服务于前端的后端。提出这个概念的目的是为了解决什么问题呢？从大的方向来说，主要有以下两个方面：
本文比较了标准 API 和服务，以通过 Internet 查询数据以进行分析、集成和数据管理。
Web应用在防火墙内部运行，它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行，通过较低带宽、较高延迟的互联网或移动网路访问。
作者 | Anupama Pathirage 译者 | 明知山 策划 | 丁晓昀 在当今的数字转型时代，应用程序和 Web 服务之间的相互对话是不可避免的，我们需要通过 API 来实现这些应用程序之间的通信。各种协议和规范定义了消息通过网络传递的语义和语法，最终形成了一种 API 架构。 在本文中，我们将探讨如何使用 GraphQL 和 Ballerina 将 MySQL 数据库中的数据作为 API 公开出来。GraphQL 是一种抽象了底层数据源的规范，借助 GraphQL，开发人员能够灵活地使
在上一篇文章RPC vs REST vs GraphQL中，对于这三者的优缺点进行了比较宏观的对比，而且我们也会发现，一般比较简单的项目其实并不需要GraphQL，但是我们仍然需要对新的技术有一定的了解和掌握，在新技术普及时才不会措手不及。
导语 | 年久失修的老接口堪称所有程序员们的噩梦，它们逻辑复杂、严重卡顿、无人维护，令经手的开发头痛不已。本文将为大家分享通过nodejs + graphQL + redis + schedule技术组合对老接口进行优化提速，提升前端体验的原理与实践，希望与大家一同交流。文章作者：艾瑞坤，腾讯前端研发工程师。
此文是作者考虑 GraphQL 在 Node.js 架构中的落地方案后所得。从最初考虑可以（以内置中间件）加入基础服务并提供完整的构建、发布、监控支持，到最终选择不改动基础服务以提供独立包适配，不限制实现技术选型，交由业务团队自由选择的轻量方式落地。中间经历了解除误解，对收益疑惑，对最初定位疑惑，最终完成利弊权衡的过程。
正如我之前所写， GraphQL是下一代API技术，它正在改变客户端应用程序与后端系统的通信方式以及后端系统的设计方式。
过去几年中，GraphQL 已经成为一种非常流行的 API 规范，该规范专注于使客户端（无论是客户端、前端还是第三方）的数据获取更加容易。
在API安全威胁不断加剧、多样化，数字化系统面临着巨大的安全挑战背景下，企业必须积极构建API安全能力。而企业API安全防护的首要任务是API资产进行清晰了解和有效管理。本期，我们将揭示API资产识别的关键技术，以帮助企业高效清晰地完成API资产梳理工作。
为了介绍使用ASP.NET Core构建GraphQL服务器，本文需要介绍一下GraphQL，其实看官网的文档就行。
编者按：本文作者奇舞团前端开发工程师何文力，同时也是 W3C CSS 工作组成员。
即使与 REST API 打交道这么多年，当我第一次了解到 GraphQL 和它试图解决的问题时，我还是禁不住把本文的标题发在了 Twitter 上。
作者 | Netflix 技术博客 译者 | 刘雅梦 策划 | 蔡芳芳 借助最新的数据网格平台（Data Mesh Platform），Netflix Studio 中的数据移动进入到了一个新阶段。这种配置驱动的平台在创建新管道时显著地缩短了前置时间，同时提供了新的支持特性，比如端到端的模式演进（schema evolution）、自助式 UI 和安全数据访问等。 1背景 未来几年，Netflix 上的大部分内容都将来自其自己的工作室（Netflix Studio）。Netflix 电影或电视据从开始宣传
本文首先介绍了 GraphQL，再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL，详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送，并附有使用示例，边用边学印象深刻~
当一个应用的规模逐渐扩张，其所包含的应用状态一般也会变得更加复杂。作为开发者，我们可能既要协调从多个远端服务器发送来的数据，也要管理好涉及 UI 交互的本地数据。我们需要以一种合适的方法存储这些数据，让应用中的组件可以简洁地获取这些数据。 许多开发者告诉过我们，使用 Apollo Client 可以很好地管理远端数据，这部分数据一般会占到总数据量的 80% 左右。那么剩下的 20% 的本地数据（例如全局标志、设备 API 返回的结果等）应该怎样处理呢？ 过去，Apollo 的用户通常会使用一个单独的 Red
尽管名为GraphQL，但它并不是一种简单的查询语言。这是一个全面解决现代应用与云服务之间连接问题的方案。因此，它构成了现代应用程序开发堆栈中一个新的重要层的基础:数据图。这个新层将公司的所有应用程序数据和服务集中在一个地方，具有一致的、安全的、易用的界面，这样任何人都可以在最小的摩擦下使用它。
GraphQL 这个名词已经火了一段时间，但是一直没有体验过，无意中发现了一篇使用体验的文章，就想着翻译下分享给大家，如果翻译有问题的，还望批评指正。译文出自：掘金翻译计划[1]
服务端API的设计与开发，为客户端提供产品业务所需要的各种功能和数据接口。随着APP产品的迭代更新，APP Server提供的接口往往也会进行多个版本的迭代更新。如何优雅的维护接口的稳定性，设计扩展性满足将来一定的业务需求变更，一直是从事服务端接口开发工程师需要不断思考的问题。
本文中，你会学到 GraphQL 类型系统的所有细节并且它是如何去描述什么样的数据是可以被查询的。既然 GraphQL 可以再任何后端框架和编程语言中使用，所以我们暂且不谈 GraphQL 的实现细节，只聚焦于核心概念。
产品需求增加，页面需要增加功能，数据也就相应的要增加显示，那么REST接口也需要做增加，这种无可厚非。
Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
GraphQL 日渐成为数据查询的主流标准之一。每天都会产生许多围绕这项技术发展的精彩讨论和新工具。GraphQL最棒的特性就是提供了一个丰富语言集来描述获取数据的API。但是用户该如何描述这种查询语言，以及GraphQL这项核心技术本身呢？let's talk!
APIJSON是一种基于JSON格式的API接口开发框架。它的目标是简化后端开发人员编写和维护接口的工作，同时提供灵活、高效、安全的接口访问方式。APIJSON通过解析请求的JSON参数，动态生成SQL语句，并自动执行数据库操作，将结果以JSON形式返回给客户端。它支持多种复杂查询和操作，如分页、条件查询、关联查询、嵌套查询等。APIJSON还提供了权限控制、数据过滤、数据校验等功能，保护数据安全和一致性。通过APIJSON，开发人员可以快速构建稳定、高效的API接口，提升开发效率和代码质量。
我认为，GraphQL 将改变世界。将来，你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢？我个人最讨厌的是，社区一直在宣传 GraphQL 的好处，而这些好处却非常普通，并且与 GraphQL 实际上没有任何关系。如果我们想推广采用，那么我们应该诚实，应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础，因为它代表了我在社区中经常听到的观点。如果你读了整篇文章，当然这会花一些时间，你就会完全理解，为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
本文最初发布于 Max Desiatov 的个人博客，经原作者授权由 InfoQ 中文站翻译并分享。
本文的目的是提供一份快速指南 -- 《如何快速在如何在 Node.js 中创建安全的 GraphQL API》。
REST作为一种现代网络应用非常流行的软件架构风格，自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性，可扩展性，伸缩性受到广大Web开发者的喜爱。
有一段时间没怎么写文章了，今天提笔写一篇自己对 API 设计的思考。首先，为什么写这个话题呢？其一，我阅读了《阿里研究员谷朴：API 设计最佳实践的思考》一文后受益良多，前两天并转载了这篇文章也引发了广大读者的兴趣，我觉得我应该把我自己的思考整理成文与大家一起分享与碰撞。其二，我觉得我针对这个话题，可以半个小时之内搞定，争取在 1 点前关灯睡觉，哈哈。
在 API 工艺的世界里，没有比设计更受热议的领域了。从 REST、gRPC 到 GraphQL，有许多方法可以设计和标准化 Web API 交互。今天，我们将注意力转向另一种方法，JSON API，JSONAPI.org 上详细介绍的用于构建 API 的规范。
作为 Facebook 在 2015 年推出的查询语言，GraphQL 能够对 API 中的数据提供一套易于理解的完整描述，使得客户端能够更加准确的获得它需要的数据
本文讨论了四种主要的 API 架构风格，比较它们的优缺点，并重点介绍每种情况下最适合的 API 架构风格。
两个单独的应用程序需要中介程序才能相互通信。因此，开发人员经常需要搭建桥梁——也就是应用程序编程接口（API），来允许一个系统访问另一个系统的信息或功能。
作者 | Nitesh Kumar 译者 | 张卫滨 策划 | Tina API 对于组织来讲正变得越来越重要，但是，构建安全、可扩展的 API 并非易事。本文从执行环境、API 技术、安全性等角度出发，介绍了如何构建高效、可扩展的 API。 本文最初发表于 Salesforce 站点，经作者 Nitesh Kumar 授权，由 InfoQ 中文站翻译分享。 API 是一个重要的工具，允许合作伙伴、开发人员和其他应用消费我们提供的微服务，与之进行通信，并基于此构建各种各样的功能。 高质量的 AP
dapp[5]的数量继续爆炸性增长，对开发人员（使用 Solidity[6]或其他区块链语言的）的需求[7]也越来越大。
今天的数据驱动型企业不仅需要针对实时数据作出快速响应要，而且还必须执行复杂的查询以解决复杂的业务问题。 例如，客户个性化系统需要将历史数据集与实时数据流结合起来，以便立即向客户提供最相关的产品建议。提供关键任务的实时业务观察能力的运营分析系统也必须如此，例如，在线支付供应商需要监测其全球范围内的交易，以发现可能预示金融欺诈的异常情况。 或者想象一个网上学习平台需要为学区客户和内部客户团队提供关于学生和教师使用情况的最新洞察力。或者是一个市场新闻供应商，需要监测并确保其金融客户在狭窄的窗口内获得准确的、相关的
作为一名前端开发人员，GraphQL对于我们来说是令人难以置信的好用。它可以用来简化数据访问，这让我们的工作变得更加容易。
原文链接：https://www.sitepoint.com/rest-api/[1]
作者 | Khalil Stemmler 策划 | 田晓旭 在服务器上使用 GraphQL 代替 REST 是有很多好处的，使用 Apollo Client 取代自己编写的数据获取逻辑也有很多优势。在这篇文章中，我们主要讨论 GraphQL 最突出的架构优势。 本文最初发布于 khalilstemmler.com 网站，经原作者授权由 InfoQ 中文站翻译并分享。 在过去的几年中，我们已经看到各种规模和形态的公司都开始在整个组织中逐渐采用 GraphQL，例如 Expedia、Nerdwallet 和 A
领取专属 10元无门槛券
手把手带您无忧上云
