GraphQL 是由 Facebook 开发并开源的。提到 GraphQL ,大家自然而然会提起 RESTful api。下面对比一下 RESTful api 和 GraphQL 的优缺点。
技术公司采用微服务架构已经十多年了,结果好坏参半。微服务之间的依赖关系导致在修改一个服务时也需要修改其他服务,微服务的优势因此打了折扣。这就是所谓的紧密耦合。但组件之间的依赖关系是不可避免的。
上一篇文章《构建基于 Rust 技术栈的 GraphQL 服务(2)- 查询服务第一部分》中,介绍了构建 GraphQL Schema、整合 Tide 和 async-graphql,以及验证 query 服务。
REST(表述性状态传输)API 是一种应用程序接口 (API) 的架构风格,它使用 HTTP 请求来访问和使用数据。该数据可用于GET、PUT、POST和DELETE数据类型,指的是对资源的读取、更新、创建和删除操作。 RESTful API 使用 HTTP 方法在处理数据时执行 CRUD(创建、读取、更新和删除)过程。 为了促进缓存、AB 测试、身份验证和其他过程,标头向客户端和服务器提供信息。 主体包含客户端想要传输到服务器的数据,例如请求的有效负载。
上一篇文章《crate 选择及环境搭建》中,我们对 HTTP 服务器端框架、模板引擎库、GraphQL 客户端等 crate 进行了选型,以及对开发环境进行了搭建和测试。另外,还完成了最基本的 handlebars 模板开发,这是 Rust web 开发的骨架工作。本篇文章中,我们请求 GraphQL 服务器后端提供的 API,获取 GraphQL 数据并进行解析,然后将其通过 handlebars 模板展示
GraphQL 是一种针对 Graph(图状数据)进行查询特别有优势的 Query Language(查询语言),所以叫做 GraphQL。它跟 SQL 的关系是共用 QL 后缀,就好像「汉语」和「英语」共用后缀一样,但他们本质上是不同的语言。GraphQL 跟用作存储的 NoSQL 没有必然联系,虽然 GraphQL 背后的实际存储可以选择 NoSQL 类型的数据库,但也可以用 SQL 类型的数据库,或者任意其它存储方式(例如文本文件、存内存里等等)。
作者简介 工业聚,携程高级前端开发专家,react-lite, react-imvc, farrow 等开源项目作者。 兰迪咚,携程高级前端开发专家,对开发框架及前端性能优化有浓厚兴趣。 一、前言 过去两三年,携程度假前端团队一直在实践基于 GraphQL/Node.js 的 BFF (Backend for Frontend) 方案,在度假BU多端产品线中广泛落地。最终该方案不仅有效支撑前端团队面向多端开发 BFF 服务的需要,而且逐步承担更多功能,特别在性能优化等方面带来显著优势。 我们观察到有些前端
在 Redux 应用中获取和管理数据需要做许多工作。正如 Sashko Stubailo 指出的:
GraphQL是一种现代的API查询语言,它在现代Web应用中得到了广泛的应用,因为它提供了一种高效、灵活且强大的方式来获取数据
GraphQL提供了一种灵活而有效的方式来查询服务器中的数据。 它正在成为设计后端的流行技术,通常会替换或封装一些不灵活的REST API,并让客户负责决定他们需要的数据。 现在有许多用于编写JavaScript的GraphQL客户端和服务器的库和框架,其中最着名的是Apollo和Graphcool 。 Apollo团队还开发了针对WebSockets的GraphQL协议,该协议主要用于Apollo Client和Graphcool中的Subscriptions。
前面我们介绍了GraphQL的概念和基础知识,这篇文章记录下使用Nestjs+GraphQL搭建Node服务。
我认为,GraphQL 将改变世界。将来,你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢?我个人最讨厌的是,社区一直在宣传 GraphQL 的好处,而这些好处却非常普通,并且与 GraphQL 实际上没有任何关系。如果我们想推广采用,那么我们应该诚实,应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础,因为它代表了我在社区中经常听到的观点。如果你读了整篇文章,当然这会花一些时间,你就会完全理解,为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
近日,代码托管平台 GitHub 于当地时间 8 月 13 日周五这天正式废除了基于密码的 Git 身份验证。从 09:00 PST (PST是北美太平洋标准时间,北京时间 14 日 0 点)开始,使用 GitHub 开发者将需要切换到基于令牌的身份验证去执行 Git 操作,基于令牌的认证包括个人接入、OAuth、SSH Key 活 GitHub App 安装令牌。
我们很熟悉以REST实现的API,可以用任何能够发出http 请求的库或者工具来测试REST API。去年随着GraphQL在全球风靡,它也出现在了最近两期的ThoughtWorks技术雷达中,当我们面对新的GraphQL APi时,QA应如何应对? 知彼知己,方能百战百胜,下面让我们首先来看看什么是GraphQL,它和传统的REST API又有什么不同?
注意:GraphQL 是 api 的查询语言,而不是数据库。从这个意义上说,它是数据库无关的, 而且可以在使用 API 的任何环境中有效使用,我们可以理解为 GraphQL 是基于 API 之上的一 层封装,目的是为了更好,更灵活的适用于业务的需求变化
GraphQL 由于其灵活性和高效性,已经成为构建 API 的热门选择。当与 React.js 结合使用时,这个强大的 JavaScript 库为创建动态、响应式的 Web 应用程序打开了无限的可能性。在本指南中,我们将介绍如何将 GraphQL 无缝集成到您的 React.js 项目中。
首先是小程序端选型的问题,我们今年以前的所有小程序都是原生+uni来实现的,再早一点也用到过 wepy,但主要还是 uni。但今年由于 vue3 的到来和对于 typescript的应用,我们需要一个能对 typescript + vue3支持较好的小程序方案。现在市面对于这个需求支持最好的就是 taro3 了。
开源的世界里到处都是“奇珍异宝”,那些琳琅满目的开源项目,它们各有特色有的是简单清爽的小工具,有的是令人称奇的黑科技,还有的是解决痛点的技术方案。这些开源项目处处散发着“诱人”的气息,让人跃跃欲试、欲罢不能。
前后端分离指的是将Web应用程序的前端部分(用户界面)和后端部分(服务器逻辑、数据处理)分开,独立开发和部署。前端通常使用现代JavaScript框架(如React、Vue、Angular)进行开发,而后端使用服务器端语言和框架(如Django、Express等)进行开发。
当微服务架构中的服务被外部的客户端访问时,可以共享有关身份验证和传输的一些常见请求。API网关提供了一个共享层去处理服务协议之间的差异,同时满足特定客户端(像PC端浏览器,移动端设备和传统系统)的需求。
在这个数字时代,我们的日常生活中充斥着各种应用程序和系统之间的交互。无论是社交媒体、在线购物还是智能家居设备,它们都需要通过API(应用程序接口)来实现数据的传输和通信。然而,这些看似简单的操作背后隐藏着复杂的协议。
APISIX API 网关提供负载均衡、动态上行、灰度发布、熔断、鉴权、可观测等丰富的流量管理功能。
新项目采用了vue3开发,而目前vue对应的QraphQL模块vue-apollo对使用typescript开发的vue3框架支持不是很好(目前正在开发的Vue Apollo 4 将支持 Vue 3),没法利用typescript来检查GraphQL接口拉回来的数据,这里记录一下处理这些问题的方式。
英国卫报创建了一个讨论和资产共享工具 Pinboard ,并将其整合到公司使用的各种内容管理平台中。该解决方案使用了一系列技术,包括用于编写业务逻辑的 Typescript、用于执行代码的无服务器服务、API 端点和 GraphQL 服务器,以及用于存储的 AWS RDS(PostgreSQL)。
API(Application Programming Interface)是现代软件的构建块之一,它允许不同的应用程序之间进行通信和协作,进而使得开发者能够创建出更为动态、灵活且具有扩展性的软件。随着互联网技术的不断发展,各种API规范也随之涌现,其中最常见的API风格包括:RESTful API、GraphQL API、RPC API和SOAP API。
外部客户端访问微服务架构中的服务时,服务端会对认证和传输有一些常见的要求。API 网关提供共享层来处理服务协议之间的差异,并满足特定客户端(如桌面浏览器、移动设备和老系统)的要求。 微服务和消费者 微服务是面向服务的架构,团队可以独立设计、开发和发布应用程序。它允许在系统各个层面上的技术多样性,团队可以在给定的技术难题中使用最佳语言、数据库、协议和传输层,从而受益。例如,一个团队可以使用 HTTP REST 上的 JSON,而另一个团队可以使用 HTTP/2 上的 gRPC 或 RabbitMQ 等消息代理
外部客户端访问微服务架构中的服务时,服务端会对认证和传输有一些常见的要求。API 网关提供共享层来处理服务协议之间的差异,并满足特定客户端(如桌面浏览器、移动设备和老系统)的要求。
一个GraphQL查询可以包含一个或者多个操作(operation),类似于一个RESTful API。操作(operation)可以使两种类型:查询(Query)或者修改(mutation)。我们看一个例子:
Web应用在防火墙内部运行,它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行,通过较低带宽、较高延迟的互联网或移动网路访问。
NestJS 最早在 2017.1 月立项,2017.5 发布第一个正式版本,它是一个基于 Express,使用 TypeScript 开发的后端框架。设计之初,主要用来解决开发 Node.js 应用时的架构问题,灵感来源于 Angular。在本文中,我将粗略介绍 NestJS 中的一些亮点。
FastAPI 是一个用于构建 API 的现代、快速(高性能)的 web 框架,使用 Python 3.6+ 并基于标准的 Python 类型提示。
在构建 Rust 异步 GraphQL 服务:基于 tide + async-graphql + mongodb(3)- 第一次重构之后,因这段时间事情较多,所以一直未着手变更服务的开发示例。现在私事稍稍告一阶段,让我们一起进行变更服务的开发,以及第二次重构。
微服务架构是一种将应用程序构建为一组小服务的方法,每个服务运行在其自己的进程中,并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务能力构建,可以独立部署,由完全自治的团队维护。在我们深入构建微服务的过程之前,了解 GraphQL 在此架构中的作用非常重要。
比如 GET 请求 /students 查询所有学生,/students/1 查询 id 为 1 的学生
Egor Romanov 曾被朋友邀请到一家初创公司担任 CTO,他先组建了一支工程师团队,然后着手构建后端、Web 管理门户和移动应用,并决定使用微服务架构来构建后端。不幸的是,这个初创业务未能获得市场关注,公司也在几个月后就宣布倒闭。回顾整个创业历程,Egor Romanov 总结了一些经验与教训。以下为他的自述。
作者 | Khalil Stemmler 策划 | 田晓旭 在服务器上使用 GraphQL 代替 REST 是有很多好处的,使用 Apollo Client 取代自己编写的数据获取逻辑也有很多优势。在这篇文章中,我们主要讨论 GraphQL 最突出的架构优势。 本文最初发布于 khalilstemmler.com 网站,经原作者授权由 InfoQ 中文站翻译并分享。 在过去的几年中,我们已经看到各种规模和形态的公司都开始在整个组织中逐渐采用 GraphQL,例如 Expedia、Nerdwallet 和 A
上一篇文章中,我们对后端基础工程进行了初始化。其中,笔者选择 Rust 生态中的 4 个 crate:tide、async-std、async-graphql、mongodb(bson 主要为 mongodb 应用)。虽然我们不打算对 Rust 生态中的 crate 进行介绍和比较,但想必有朋友对这几个选择有些疑问,比如:tide 相较于 actix-web,可称作冷门、不成熟,postgresql 相较于 mongodb 操作的便利性等。 笔者在 2018-2019 年间,GraphQL 服务后端,一直使用的是 actix-web + juniper + postgresql 的组合,应用前端使用了 typescript + react + apollo-client,有兴趣可以参阅开源项目 actix-graphql-react。 2020 年,笔者才开始了 tide + async-graphql 的应用开发,在此,笔者简单提及下选型理由——
如果你正在开发一个大型/复杂的应用,并且你经常需要快速,可靠地升级部署 ,那么微服架构是一个不错的选择。
近一两年来 GraphQL 和 TypeScript 的使用都程爆发式增长,当两者与React结合使用时,它们可以为开发人员提供理想的开发体验。
https://www.dsinternals.com/wp-content/uploads/eu-19-Grafnetter-Exploiting-Windows-Hello-for-Business.pdf
我们通过构建收银台体验开启了我们的 GraphQL 采用之旅。当 我们用 GraphQL 构建收银台应用程序 时,我们看到了采用 GraphQL 的巨大好处,这成为我们的指路明灯。我们构建了更多的应用程序,提供了基础设施支持,发布了一个公共 GraphQL API,并在全公司提供了培训和学习材料。我们还建立了一个标准机构,提供了一个 GraphQL 工具 fanny pack,并构建了示例应用程序来帮助团队开始使用 GraphQL。
随着互联网的快速发展,应用程序接口(API)成为了不同系统和服务之间进行数据交换和通信的重要方式,然而API接口的广泛使用也引发了一系列的安全问题,在当今数字化时代,API接口安全问题的重要性不容忽视,恶意攻击者利用漏洞和不当的API实施,可能导致数据泄露、身份验证问题以及系统的完整性和可用性受到威胁,本文将探讨API接口安全问题的重要性并介绍常见的安全威胁和挑战,还将探讨如何保护API接口免受这些威胁并介绍一些最佳实践和安全措施
在大多数 React 应用程序中,应用程序需要来自 API 或服务器的数据才能正常运行。也会将数据从应用程序提交到服务器以接收某种响应。有几种方法可以将此数据发送/获取到 API 或服务器,可以使用内置的 API 或外部 npm 包来实现。
作者 | Murat Çorlu 译者 | 平川 策划 | 闫园园 “前端”的新职责和挑战都将越来越多。我们每天都听到新的 Web API,如 Web Assembly、Web Worker、Web GPU 等。我们为应对那些新增的层所做的工作不仅和“基本 UI”相关。相反,我们会借助浏览器提供的新功能,将之前在后端处理的一些东西移到“前端”。 本文最初发布于的 Murat Çorlu 个人博客。 在云服务的高度抽象的帮助下,大多数项目的后端工作都日益减少。仅使用一些公有云服务(如 Fireb
过去几年中,GraphQL 已经成为一种非常流行的 API 规范,该规范专注于使客户端(无论是客户端、前端还是第三方)的数据获取更加容易。
根据 Gartner 对微服务的定义:“微服务是范围狭窄、封装紧密、松散耦合、可独立部署且可独立伸缩的应用程序组件。”
Spring I/O是Spring开发者的技术大会,这里DD给大家整理了Spring I/O 2023中的优质视频,都是超级干货!
作者 | Marc-André Giroux 本文最初发布于 Marc-André Giroux 博客,由 InfoQ 中文站翻译并分享。 这个话题昨天在推特上爆发了,我想应该用更长的篇幅回顾一下作者的一些观点,澄清一些误解,我们一个个过一遍。 【推文 1 】GraphQL 使你的公共 API 等同于一个通用数据库,更糟糕的是——一个通用图形数据库,维护工作量高得惊人;锁定查询功能意味着你只是在运行普通的 API,但不锁定它意味着无限的性能工作。 (https://twitter.com/jmhodges
前 3 篇文章中,我们初始化搭建了工程结构,选择了必须的 crate,并成功构建了 GraphQL 查询服务,以及对代码进行了第一次重构。本篇文章,是我们进行 GraphQL 服务后端开发的最后一篇:变更服务。本篇文章之后,GraphQL 服务后端开发第一阶段告一阶段,之后我们进行 基于 Rust 的 Web 前端开发。本系列文章中,采用螺旋式思路,Web 前端基础开发之后,再回头进行 GraphQL 后端开发的改进。
来源:InfoQ、作者:Egor Romanov、译者:核子可乐、策划:凌敏 初创公司在技术上到底要踩多少“坑”? Egor Romanov 曾被朋友邀请到一家初创公司担任 CTO,他先组建了一支工程师团队,然后着手构建后端、Web 管理门户和移动应用,并决定使用微服务架构来构建后端。不幸的是,这个初创业务未能获得市场关注,公司也在几个月后就宣布倒闭。回顾整个创业历程,Egor Romanov 总结了一些经验与教训。以下为他的自述。 空降 CTO 接手“烂摊子” 第一次受邀到初创公司担任技术主管的时候,
领取专属 10元无门槛券
手把手带您无忧上云