随着多终端、多平台、多业务形态、多技术选型等各方面的发展,前后端的数据交互,日益复杂。
作为 Facebook 在 2015 年推出的查询语言,GraphQL 能够对 API 中的数据提供一套易于理解的完整描述,使得客户端能够更加准确的获得它需要的数据
古映杰,携程研发高级经理,负责前端框架和基础设施的设计、研发与维护。开源项目react-lite和react-imvc作者。
本文比较了标准 API 和服务,以通过 Internet 查询数据以进行分析、集成和数据管理。
之前2020-5-6-restful理解 - huangtengxiao和大家提及了RESTfulAPI的一个弊端,就是接口膨胀。
通过 HTTP 发送数据,许多开发人员已经在用 REST 了,而 GraphQL 通常被认为是一种代替遗留 REST API 的技术。本文将对比两者各自的优势、劣势以及它们之间的差异,希望能为你今后项目的技术选型提供帮忙。
在过去的将近半年的时间里,作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务,与更早出现的 SOAP 和 REST 相比,GraphQL 其实提供的是一套相对完善的查询语言,而不是类似 REST 的设计规范,所以需要语言的生态提供相应的框架支持,但是由于从它开源至今也只有两三年的时间,所以在使用的过程中,尤其是在微服务架构中实践时确实还会遇到很多问题。
作为一名前端开发人员,GraphQL对于我们来说是令人难以置信的好用。它可以用来简化数据访问,这让我们的工作变得更加容易。
产品需求增加,页面需要增加功能,数据也就相应的要增加显示,那么REST接口也需要做增加,这种无可厚非。
Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性,可扩展性,伸缩性受到广大Web开发者的喜爱。
REST作为一种现代网络应用非常流行的软件架构风格,自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性,可扩展性,伸缩性受到广大Web开发者的喜爱。
编者按:本文作者奇舞团前端开发工程师何文力,同时也是 W3C CSS 工作组成员。
GraphQL是Facebook提出的一种数据查询语言,核心特性是数据聚合和按需索取,目前被广泛应用于前后端之间,解决客户端灵活使用数据问题。本文介绍的是GraphQL的另一种实践,我们将GraphQL下沉至后端BFF(Backend For Frontend)层之下,结合元数据技术,实现数据和加工逻辑的按需查询和执行。这样不仅解决了后端BFF层灵活使用数据的问题,这些字段加工逻辑还可以直接复用,大幅度提升了研发的效率。
从2023年7月起我所有可公开的文档都保存在了 GitHub Discussions 上,作为博客、IED 编辑器,以及评论使用,GitHub Discussions 是完全没问题的。
本文介绍今年上半年使用的的一些技术,做一些个人的学习记录,温故而知新。主要包含了Nestjs、TypeGraphQL、TypeORM相关的知识。本文示例代码以提交到github,可以在这里查看。
尽管名为GraphQL,但它并不是一种简单的查询语言。这是一个全面解决现代应用与云服务之间连接问题的方案。因此,它构成了现代应用程序开发堆栈中一个新的重要层的基础:数据图。这个新层将公司的所有应用程序数据和服务集中在一个地方,具有一致的、安全的、易用的界面,这样任何人都可以在最小的摩擦下使用它。
举一个例子,例如现在有这么一个查询书籍信息的接口:/book/info,按照我们之前的解决方案,我们一般会传一个类似book_id的参数到这个接口,然后接口把书籍信息返回给我们
我认为,GraphQL 将改变世界。将来,你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢?我个人最讨厌的是,社区一直在宣传 GraphQL 的好处,而这些好处却非常普通,并且与 GraphQL 实际上没有任何关系。如果我们想推广采用,那么我们应该诚实,应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础,因为它代表了我在社区中经常听到的观点。如果你读了整篇文章,当然这会花一些时间,你就会完全理解,为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
英国卫报创建了一个讨论和资产共享工具 Pinboard ,并将其整合到公司使用的各种内容管理平台中。该解决方案使用了一系列技术,包括用于编写业务逻辑的 Typescript、用于执行代码的无服务器服务、API 端点和 GraphQL 服务器,以及用于存储的 AWS RDS(PostgreSQL)。
学习成本倒也不是特别大的问题,程序员们本能上还是喜欢接触新东西的,这会让他们有一种虚假的获得感。
graphw00f是一款针对GQL节点的GraphQL指纹识别工具,该工具可以混合发送良性和恶意查询请求,以帮助广大研究人员识别和确定目标应用程序背后的GraphQL引擎。
过去几年中,GraphQL 已经成为一种非常流行的 API 规范,该规范专注于使客户端(无论是客户端、前端还是第三方)的数据获取更加容易。
大家好,我叫储惠龙(实名上网),你可以叫我小龙人,00 后一枚。目前从事后端开发工作。
服务端API的设计与开发,为客户端提供产品业务所需要的各种功能和数据接口。随着APP产品的迭代更新,APP Server提供的接口往往也会进行多个版本的迭代更新。如何优雅的维护接口的稳定性,设计扩展性满足将来一定的业务需求变更,一直是从事服务端接口开发工程师需要不断思考的问题。
自从 Web 开始迅猛发展,对程序员来说开发 API 是一项很艰巨的任务。我们开发 API 的方式必须随着时间的推移而发展,以便我们始终可以开发良好、直观且设计良好的API。
每隔一段时间就能看到一篇 GraphQL 的文章,但是打开文章一看,基本上就是简单的介绍下 GraphQL 的特性。很多文章其实就是 github 上找个 GraphQL 的项目,然后按照对应的 demo 跑起来而已。有些文章明显是没有完整的项目实践经历,却在狂吹 GraphQL 的各种优点,让不熟悉 GraphQL 的同学以为这是神丹妙药,弄不好还要在项目中实践一番。
为了介绍使用ASP.NET Core构建GraphQL服务器,本文需要介绍一下GraphQL,其实看官网的文档就行。
REST作为一种现代网络应用非常流行的软件架构风格受到广大WEB开发者的喜爱,在目前软件架构设计模式中随处可见REST的身影,但是随着REST的流行与发展,它的一个最大的缺点开始暴露出来:
GraphQL是一种查询语言、一种执行引擎和一种规范,它引领开发人员重新思考应该怎样去构建客户端和API。
作者简介 工业聚,携程高级前端开发专家,react-lite, react-imvc, farrow 等开源项目作者。 兰迪咚,携程高级前端开发专家,对开发框架及前端性能优化有浓厚兴趣。 一、前言 过去两三年,携程度假前端团队一直在实践基于 GraphQL/Node.js 的 BFF (Backend for Frontend) 方案,在度假BU多端产品线中广泛落地。最终该方案不仅有效支撑前端团队面向多端开发 BFF 服务的需要,而且逐步承担更多功能,特别在性能优化等方面带来显著优势。 我们观察到有些前端
Karate是一款将接口自动化测试、mock、性能测试集合到一起的测试框架。采用BDD语法,对于无编程能力的人也很容易;另外提供强大的JSON、XML断言功能及并发执行。以上的内容翻译自Karate官网,也许你看到这些描述时仍然不能直观感受到Karate和其他接口测试框架的区别,接下来让我们看一个Karate编写的接口测试demo。以下是一个Graphql的接口,下面是利用Karate实现该接口测试的代码
本文首先介绍了 GraphQL,再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL,详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送,并附有使用示例,边用边学印象深刻~
时间退回到 2012年的一个下午, 美国加利福尼亚州, facebook 的工程师们发现他们才上架没多久的移动端应用就收到了很多差评, 用户反映app响应慢,耗电严重等,经过分析后发现, 应用在第一次启动时, 会请求大量的后端api接口, 这其中包括用户自己的信息, 好友发布的内容, 以及其他的热点信息, 等等。太多的 rest api 请求, 这就是问题所在。
作者 | Jennifer Shin、Tejas Shikhare、Will Emmanuel
内容来源:2018 年 6 月 9 日,国内某大型电商公司用户体验部门前端开发专家邓若奇在“杭州第一届 GraphQLParty—GraphQL与领域驱动带来的协同价值”进行《基于SPA架构的GraphQL工程实践》演讲分享。IT 大咖说(微信id:itdakashuo)作为独家视频合作方,经主办方和讲者审阅授权发布。
英文:Igor Ribeiro Lima 译文:众成翻译/乐何 zcfy.cc/article/graphql-overview-build-a-to-do-list-api-with-a-react-front-end-mdash-sitepoint 设想你想要参考食谱烤一个蛋糕。你将需要一些原料,并且一些合适的量。如果你能拿一个盒子装好你烘焙所需要的各种原料 ,并且已经称量好匹配菜谱的份量,那肯定会让烘焙更简单。如果你把前端 UI设想成一块蛋糕的话,那这就是GraphQL所做的事。 在本教程中我们将
Graphql 是一种查询语言、一个执行引擎和一个规范,它引导开发人员重新思考如何构建客户端和 API 应用程序
最近,GraphQL 在构建后端 API 方面获得越来越多大公司的青睐, 如 PayPal、Facebook、Hasura、去哪儿等公司都做了大量实践。
大家好,我是阿里的邓若奇。我和 Scott 是好友,非常幸运今天站在这里和大家面对面的交流。我是一名前端,听说今天来的前端特别多,非常高兴,压力也很大。
先回到会议的主题,为什么会开这么一个会议?原本这个会议报名的时候希望可以控制到 100 人之内,不要超过 120 人,结果报到 250 人还爆满了,后来没有办法,我们只能从工作经验来筛选,选择工作经验在三年以上的比较资深的工程师,和一部分 2 年经验工作经验的,还有 5 年的,10 年甚至更久的从业者。
这时候前端MM拿到这个结果后,傻了眼!这里怎么能直接返回author_id呢,难道直接把author_id显示在界面上么?不可能啊,界面上要显示的是author_name才行!
本文最初发布于 Max Desiatov 的个人博客,经原作者授权由 InfoQ 中文站翻译并分享。
本文的目的是提供一份快速指南 -- 《如何快速在如何在 Node.js 中创建安全的 GraphQL API》。
GraphQL 日渐成为数据查询的主流标准之一。每天都会产生许多围绕这项技术发展的精彩讨论和新工具。GraphQL最棒的特性就是提供了一个丰富语言集来描述获取数据的API。但是用户该如何描述这种查询语言,以及GraphQL这项核心技术本身呢?let's talk!
GraphQL 这个名词已经火了一段时间,但是一直没有体验过,无意中发现了一篇使用体验的文章,就想着翻译下分享给大家,如果翻译有问题的,还望批评指正。译文出自:掘金翻译计划[1]
2019年即将到来,各位同学2018年辛苦了。 不管大家2018年过的怎么样,2019年还是要继续加油的! 在此我整理了个人认为在2019仍是或者将成为主流的技术与大家分享,包括前端、后端和全栈相关。
领取专属 10元无门槛券
手把手带您无忧上云