作者 | Khalil Stemmler 策划 | 田晓旭 在服务器上使用 GraphQL 代替 REST 是有很多好处的,使用 Apollo Client 取代自己编写的数据获取逻辑也有很多优势。在这篇文章中,我们主要讨论 GraphQL 最突出的架构优势。 本文最初发布于 khalilstemmler.com 网站,经原作者授权由 InfoQ 中文站翻译并分享。 在过去的几年中,我们已经看到各种规模和形态的公司都开始在整个组织中逐渐采用 GraphQL,例如 Expedia、Nerdwallet 和 A
GraphQL 由于其灵活性和高效性,已经成为构建 API 的热门选择。当与 React.js 结合使用时,这个强大的 JavaScript 库为创建动态、响应式的 Web 应用程序打开了无限的可能性。在本指南中,我们将介绍如何将 GraphQL 无缝集成到您的 React.js 项目中。
通过 HTTP 发送数据,许多开发人员已经在用 REST 了,而 GraphQL 通常被认为是一种代替遗留 REST API 的技术。本文将对比两者各自的优势、劣势以及它们之间的差异,希望能为你今后项目的技术选型提供帮忙。
当一个应用的规模逐渐扩张,其所包含的应用状态一般也会变得更加复杂。作为开发者,我们可能既要协调从多个远端服务器发送来的数据,也要管理好涉及 UI 交互的本地数据。我们需要以一种合适的方法存储这些数据,让应用中的组件可以简洁地获取这些数据。 许多开发者告诉过我们,使用 Apollo Client 可以很好地管理远端数据,这部分数据一般会占到总数据量的 80% 左右。那么剩下的 20% 的本地数据(例如全局标志、设备 API 返回的结果等)应该怎样处理呢? 过去,Apollo 的用户通常会使用一个单独的 Red
我认为,GraphQL 将改变世界。将来,你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢?我个人最讨厌的是,社区一直在宣传 GraphQL 的好处,而这些好处却非常普通,并且与 GraphQL 实际上没有任何关系。如果我们想推广采用,那么我们应该诚实,应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础,因为它代表了我在社区中经常听到的观点。如果你读了整篇文章,当然这会花一些时间,你就会完全理解,为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
新项目采用了vue3开发,而目前vue对应的QraphQL模块vue-apollo对使用typescript开发的vue3框架支持不是很好(目前正在开发的Vue Apollo 4 将支持 Vue 3),没法利用typescript来检查GraphQL接口拉回来的数据,这里记录一下处理这些问题的方式。
GraphQL is an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data.[2] GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015. GraphQL - Wikipedia
本次演讲主要介绍如何使用GraphQL,分别从前后端两个角度分析GraphQL的优劣势,对比Restful又能够给前后端协同开发带来哪些好处。
REST(表述性状态传输)API 是一种应用程序接口 (API) 的架构风格,它使用 HTTP 请求来访问和使用数据。该数据可用于GET、PUT、POST和DELETE数据类型,指的是对资源的读取、更新、创建和删除操作。 RESTful API 使用 HTTP 方法在处理数据时执行 CRUD(创建、读取、更新和删除)过程。 为了促进缓存、AB 测试、身份验证和其他过程,标头向客户端和服务器提供信息。 主体包含客户端想要传输到服务器的数据,例如请求的有效负载。
近一两年来 GraphQL 和 TypeScript 的使用都程爆发式增长,当两者与React结合使用时,它们可以为开发人员提供理想的开发体验。
前一篇文章介绍了怎么使用 ApolloServer 搭建 GraphQL server,今天看看怎么使用 ApolloClient 来执行查询。
此文是作者考虑 GraphQL 在 Node.js 架构中的落地方案后所得。从最初考虑可以(以内置中间件)加入基础服务并提供完整的构建、发布、监控支持,到最终选择不改动基础服务以提供独立包适配,不限制实现技术选型,交由业务团队自由选择的轻量方式落地。中间经历了解除误解,对收益疑惑,对最初定位疑惑,最终完成利弊权衡的过程。
接前文为 Django 配备 GraphQL API,Django 提供 GraphQL 接口服务之后,我们需要让前端来消费这些接口数据,以 Vue 为例,看一看前端如何访问后端 GraphQL API。本文提供一个跑的通的 demo,可以先收藏,后面如有需要可以直接使用。
全文以后端开发视角写作,部分涉及到前端开发的介绍可能存在错误或者不准确,欢迎在评论区斧正
很久之前其实就关注过这个技术,记得当时还是React刚刚崭露头角的时期吧。总之那时候,GraphQL感觉还只是概念完备阶段,除了FB自己内部大量使用外,好像社区并不是很健全,不过大家应该都在疯狂的讨论和跟进吧。过了2年,如今再回过头来看,已经涌现出各种开源或商用服务专注于这个领域,各种语言的框架和工具也都很完备了,感觉是时候重新接触GraphQL了。如果你的项目正处于技术选型,你正在犹豫选择一种接口风格的时刻,不妨了解一下这个神奇而强大的玩意儿~~
最近在知乎看到了这么个问题:学完Vue还有必要学习React和Node吗?[1], 有很奇妙的感觉,因为我在最开始入门前端时,也是以Vue入的门,在“学完”Vue之后, 我也有了类似的疑问,但当时的我没多想,觉得“技多不压身”,反正都是前端,以后肯定用得上,那就学呗。
最近在知乎看到了这么个问题:学完Vue还有必要学习React和Node吗?, 有很奇妙的感觉,因为我在最开始入门前端时,也是以Vue入的门,在“学完”Vue之后, 我也有了类似的疑问,但当时的我没多想,觉得“技多不压身”,反正都是前端,以后肯定用得上,那就学呗——
在 Redux 应用中获取和管理数据需要做许多工作。正如 Sashko Stubailo 指出的:
现代网站越来越多的使用前后端分离架构,先用前端 MVC 框架快速堆砌出 SPA,再用 API 获取动态数据也已经成为日常的开发内容;而用来连接前后端的 API,其重要性也自然言而喻。做为一个前端码农,认识后端的 API 设计方式也是很重要的,今天让我们针对 API 设计来一探究竟。
注意:GraphQL 是 api 的查询语言,而不是数据库。从这个意义上说,它是数据库无关的, 而且可以在使用 API 的任何环境中有效使用,我们可以理解为 GraphQL 是基于 API 之上的一 层封装,目的是为了更好,更灵活的适用于业务的需求变化
StackPath最近发布了新的门户网站,它让用户可以一站式地配置我们所提供的服务(CDN,WAF, DNS以及Monitoring)。这个项目涉及到整合不同的数据源,以及一些现有和全新的系统。虽然我们认为开发效率的优先级在一个新启动的项目中是最高的,但我们还是希望在保证足够快的开发进度的前提下,尽可能早地做一些能够保证产品长期稳定运行的技术投资,以便我们能够持续不断地在一个健壮的基础设施上添加新的功能特性。最终我们选择了Apollo GraphQL+gRPC+React+TypeScript这样一套技术栈,并对使用它们的结果感到满意。在这篇博客中,我们会解释为何选择这些技术栈,并通过一个简单的示例项目进行论述。
在Vue中集中Vue-apollo以后(如何集成请查看本专栏第六篇),就可以使用它进行查询数据了。
为了获取服务端GraphQl接口的数据,客户端需要使用apollo这个插件,三大前端框架均可以将apollo集成,下面以vue为例来说明在客户端如何集成vue-apollo这个插件。
最近在协助调研 Apollo 生成的代码是否有可能跨 Query 共享模型的问题,虽然初步结论是不能,并不是预期的结果,但是在调研过程中积累的一些经验,有必要记录下。如果你也对 Graphql 感兴趣,不妨先从 Github 的 Graphql API 来切手实践。
编者按:本文作者奇舞团前端开发工程师何文力,同时也是 W3C CSS 工作组成员。
前面我们介绍了GraphQL的概念和基础知识,这篇文章记录下使用Nestjs+GraphQL搭建Node服务。
本文最初发布于 Max Desiatov 的个人博客,经原作者授权由 InfoQ 中文站翻译并分享。
传统的api调用一般获取到的是后端组装好的一个完整对象,而前端可能只需要用其中的某些字段,大部分数据的查询和传输工作都浪费了。graphQL提供一种全新数据查询方式,可以只获取需要的数据,使api调用更灵活、高效和低成本。
随着多终端、多平台、多业务形态、多技术选型等各方面的发展,前后端的数据交互,日益复杂。
接上一篇文章,上一篇通过 express 作为 GraphQL Server 介绍了一下 GraphQL,今天说一下如何使用 Apollo Server 作为 GraphQL服务器。
在大多数 React 应用程序中,应用程序需要来自 API 或服务器的数据才能正常运行。也会将数据从应用程序提交到服务器以接收某种响应。有几种方法可以将此数据发送/获取到 API 或服务器,可以使用内置的 API 或外部 npm 包来实现。
接上一篇文章,由于 express 现在仍然是主流的 Node.js 服务端框架,所以今天看看 ApolloServer 怎样和 express 集成构建 GraphQL 服务。另外今天文章也顺便讲一下怎么使用 typescript 来实现。
Due to different dependencies, this may cause some error, see Troubleshooting below
Apollo 正在构建软件平台帮助用户在应用程序和服务中统一 GraphQL。包括:
作者简介 工业聚,携程高级前端开发专家,react-lite, react-imvc, farrow 等开源项目作者。 兰迪咚,携程高级前端开发专家,对开发框架及前端性能优化有浓厚兴趣。 一、前言 过去两三年,携程度假前端团队一直在实践基于 GraphQL/Node.js 的 BFF (Backend for Frontend) 方案,在度假BU多端产品线中广泛落地。最终该方案不仅有效支撑前端团队面向多端开发 BFF 服务的需要,而且逐步承担更多功能,特别在性能优化等方面带来显著优势。 我们观察到有些前端
一个GraphQL查询可以包含一个或者多个操作(operation),类似于一个RESTful API。操作(operation)可以使两种类型:查询(Query)或者修改(mutation)。我们看一个例子:
古映杰,携程研发高级经理,负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。
本文首先介绍了 GraphQL,再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL,详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送,并附有使用示例,边用边学印象深刻~
新增Apollo Federation网关协议的支持,用rust写基于graphql接口的微服务成为可能!改变用rust来写graphql只能做做玩具项目的现状。。。
技术公司采用微服务架构已经十多年了,结果好坏参半。微服务之间的依赖关系导致在修改一个服务时也需要修改其他服务,微服务的优势因此打了折扣。这就是所谓的紧密耦合。但组件之间的依赖关系是不可避免的。
最近一段时间关于GraphQL的讨论很多,一些项目中也相继用到了这种风格,但使用是否合理,是否存在杀鸡用牛刀这样的问题,还有待商榷。
我们的业务后台使用开发rpc服务,然后通过包一层http给前端调用。因为历史遗留问题,前期项目赶进度导致遗留了很多技术债。例如:
微服务架构是一种将应用程序构建为一组小服务的方法,每个服务运行在其自己的进程中,并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务能力构建,可以独立部署,由完全自治的团队维护。在我们深入构建微服务的过程之前,了解 GraphQL 在此架构中的作用非常重要。
最近在折腾使用Github api做个微信小程序练练手,本篇文章就是在这个过程中记录。
之前闲着无聊写的一个 Redux 项目,今天突然想把它做成动态数据源,很早之前使用 Gatsby 的时候尝试过 GraphQL 觉得不错,所以就试着集成了一下。
GraphQL提供了一种灵活而有效的方式来查询服务器中的数据。 它正在成为设计后端的流行技术,通常会替换或封装一些不灵活的REST API,并让客户负责决定他们需要的数据。 现在有许多用于编写JavaScript的GraphQL客户端和服务器的库和框架,其中最着名的是Apollo和Graphcool 。 Apollo团队还开发了针对WebSockets的GraphQL协议,该协议主要用于Apollo Client和Graphcool中的Subscriptions。
我们通过构建收银台体验开启了我们的 GraphQL 采用之旅。当 我们用 GraphQL 构建收银台应用程序 时,我们看到了采用 GraphQL 的巨大好处,这成为我们的指路明灯。我们构建了更多的应用程序,提供了基础设施支持,发布了一个公共 GraphQL API,并在全公司提供了培训和学习材料。我们还建立了一个标准机构,提供了一个 GraphQL 工具 fanny pack,并构建了示例应用程序来帮助团队开始使用 GraphQL。
看看与 React 有关的软件包的生态系统。在 Facebook 构建 React 之初,就有许多来自于开源社区第三方库的软件包。这些软件包使用 React 补充其它功能,以便提供完整的应用程序解决方
大多数人刚上手 Vuex 的时候,首先都想知道,应该往其中存放什么样的数据呢?在对这个问题给出答案的过程中,很多人(包括我)先是来到了“一股脑放进去”的阶段。但是在遭遇了首次障碍后,你很快就会领悟到:这可不是在 Vue.js 应用中管理数据的完美方案啊。
领取专属 10元无门槛券
手把手带您无忧上云