当一个应用的规模逐渐扩张,其所包含的应用状态一般也会变得更加复杂。作为开发者,我们可能既要协调从多个远端服务器发送来的数据,也要管理好涉及 UI 交互的本地数据。我们需要以一种合适的方法存储这些数据,让应用中的组件可以简洁地获取这些数据。 许多开发者告诉过我们,使用 Apollo Client 可以很好地管理远端数据,这部分数据一般会占到总数据量的 80% 左右。那么剩下的 20% 的本地数据(例如全局标志、设备 API 返回的结果等)应该怎样处理呢? 过去,Apollo 的用户通常会使用一个单独的 Red
为了介绍使用ASP.NET Core构建GraphQL服务器,本文需要介绍一下GraphQL,其实看官网的文档就行。
Coursera 的客户端开发人员钟情于 GraphQL 的灵活性,类型安全性和良好的社区支持,我们对 GraphQL 的喜爱众~所~周~知。然而,我们并没有过多讨论后端开发人员是如何看待 GraphQL 的,因为他们大多数实际上并不需要考虑 GraphQL。
作者 | Anupama Pathirage 译者 | 明知山 策划 | 丁晓昀 在当今的数字转型时代,应用程序和 Web 服务之间的相互对话是不可避免的,我们需要通过 API 来实现这些应用程序之间的通信。各种协议和规范定义了消息通过网络传递的语义和语法,最终形成了一种 API 架构。 在本文中,我们将探讨如何使用 GraphQL 和 Ballerina 将 MySQL 数据库中的数据作为 API 公开出来。GraphQL 是一种抽象了底层数据源的规范,借助 GraphQL,开发人员能够灵活地使
Appsmith 成立于 2019 年,是一款开源低代码框架。这两年发展迅猛,是现在 GitHub 上最火的低代码开发平台(18k star),目前处于正式发行阶段。Appsmith 主要用于构建管理面板、内部工具和仪表板等,允许拖放 UI 组件来构建页面,通过连接到任何 API、数据库或 GraphQL 源,并使用 JavaScript 语言编写逻辑,可以在短时间内创建内部应用程序。这种开发模式仅需了解一些基本的 JavaScript,在代码方面没有抽象层或术语需要学习,因而广受开发人员的好评。
作者 | Khalil Stemmler 策划 | 田晓旭 在服务器上使用 GraphQL 代替 REST 是有很多好处的,使用 Apollo Client 取代自己编写的数据获取逻辑也有很多优势。在这篇文章中,我们主要讨论 GraphQL 最突出的架构优势。 本文最初发布于 khalilstemmler.com 网站,经原作者授权由 InfoQ 中文站翻译并分享。 在过去的几年中,我们已经看到各种规模和形态的公司都开始在整个组织中逐渐采用 GraphQL,例如 Expedia、Nerdwallet 和 A
一个多月前,facebook 将其开源了一年多的 GraphQL 标记为 production ready ( http://graphql.org/blog/production-ready/ ),几乎同一时间,github 开放了其 GraphQL API 的 early access ( https://developer.github.com/early-access/graphql/ )。两颗重磅炸弹先后落地,是否意味着已有五年多历史,和 facebook 的 news feed 几乎同时诞生的
本文比较了标准 API 和服务,以通过 Internet 查询数据以进行分析、集成和数据管理。
原文来自Kadira Voice,标题为「Meteor’s Reactive GraphQL Is Just Awesome」。 Meteor正在着手开发一套响应式的GraphQL实现,他们在前几天放出了一份high-level technical documentation。这篇文章是该设计文档的总结和我对这个项目的一些想法。 这是 GraphQL GraphQL 是一个Facebook提出的应用层的查询语言。它有许多的伴随工具和库,比如Relay,GraphiQL,和express-graphql。同时
Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性,可扩展性,伸缩性受到广大Web开发者的喜爱。
产品需求增加,页面需要增加功能,数据也就相应的要增加显示,那么REST接口也需要做增加,这种无可厚非。
REST作为一种现代网络应用非常流行的软件架构风格,自从Roy Fielding博士在2000年他的博士论文中提出来到现在已经有了20年的历史。它的简单易用性,可扩展性,伸缩性受到广大Web开发者的喜爱。
微服务架构是一种将应用程序构建为一组小服务的方法,每个服务运行在其自己的进程中,并通过轻量级机制(通常是HTTP资源API)进行通信。这些服务围绕业务能力构建,可以独立部署,由完全自治的团队维护。在我们深入构建微服务的过程之前,了解 GraphQL 在此架构中的作用非常重要。
对于开发者而言,2017出奇的高效,不过2018年有望为IT领域带来更多发展。本文中,为了处理项目时紧跟潮流,我们会描述出每个前端编程人都需要关注的2018年JavaScript的五种主要发展趋势。
本文讨论了四种主要的 API 架构风格,比较它们的优缺点,并重点介绍每种情况下最适合的 API 架构风格。
两个单独的应用程序需要中介程序才能相互通信。因此,开发人员经常需要搭建桥梁——也就是应用程序编程接口(API),来允许一个系统访问另一个系统的信息或功能。
过去几年中,GraphQL 已经成为一种非常流行的 API 规范,该规范专注于使客户端(无论是客户端、前端还是第三方)的数据获取更加容易。
在上一篇文章RPC vs REST vs GraphQL中,对于这三者的优缺点进行了比较宏观的对比,而且我们也会发现,一般比较简单的项目其实并不需要GraphQL,但是我们仍然需要对新的技术有一定的了解和掌握,在新技术普及时才不会措手不及。
本文介绍了Mantra的核心组件和它们如何共同发挥作用的。 关注客户端 Mantra非常关注客户端,因为那是你写大部分代码的地方。我们允许客户端缓存和连接器与服务端和远端数据层交互。 ES2015 语法和 ES2015 模块 我们依赖于ES2015的多个特性和它的模块系统。为了使用Mantra,你首先需要使用Meteor 1.3,它包含了一个ES2015模块系统的实现。 React 作为 UI 我们使用React作为Mantra的UI(表现层)。你应当使用props来传递所有的数据,事件处理和库函数。 A
Web应用在防火墙内部运行,它们通过高带宽、低延迟的局域网访问服务。其他客户端在防火墙之外运行,通过较低带宽、较高延迟的互联网或移动网路访问。
请求--响应类的API的典型做法是,通过基于HTTP的Web服务器暴露一个/套接口。API定义一些端点,客户端发送数据的请求到这些端点,Web服务器处理这些请求,然后返回响应。响应的格式通常是JSON或XML。
即使与 REST API 打交道这么多年,当我第一次了解到 GraphQL 和它试图解决的问题时,我还是禁不住把本文的标题发在了 Twitter 上。
这篇稿子断断续续写了有两周,期间还在公司做了一次 “A Tour to API Evolution” 的讲座,基本上就是把中文的稿子转译了一下。我之所以要研究这样一个主题,是想从 API 的历史中找到未来前进的方向,毕竟「读史使人明智,知古可以鉴今」。
在过去的将近半年的时间里,作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务,与更早出现的 SOAP 和 REST 相比,GraphQL 其实提供的是一套相对完善的查询语言,而不是类似 REST 的设计规范,所以需要语言的生态提供相应的框架支持,但是由于从它开源至今也只有两三年的时间,所以在使用的过程中,尤其是在微服务架构中实践时确实还会遇到很多问题。
如果你仔细想想,标准和协议在任务完成后就会出现它们本来要简化的东西已经出现了一段时间了,没有两组是用同样的方法来做的。这适用于软件,移动开发如何成为标准化的最近的一个例子,你甚至可以创建一个应用程序,该应用程序将在所有主要的操作系统的工作(这不是很久以前当你必须使用不同的技术对不同型号的设备从同一家公司)。
众所周知,Prometheus和Grafana可用于监控广泛的应用程序。在本文中,我们将学习如何设置Prometheus和Grafana。我们还将看到如何将Prometheus集成为Grafana中的数据源。
英国卫报创建了一个讨论和资产共享工具 Pinboard ,并将其整合到公司使用的各种内容管理平台中。该解决方案使用了一系列技术,包括用于编写业务逻辑的 Typescript、用于执行代码的无服务器服务、API 端点和 GraphQL 服务器,以及用于存储的 AWS RDS(PostgreSQL)。
架构师的主要活动是做出正确的技术决策。选择合适的API是一项重要的技术决策。那么今天就看看API的选择问题。
低代码平台正在不断发展,新平台不断涌入市场,旧平台不断调整产品和策略,所以本篇文章的目的通过低代码平台使用者的视角引出细节,了解他们为什么使用低代码平台以及会选择哪个低代码平台来加速内部系统的开发。读者也可以点击链接向码匠分享自己的意见或建议。
上一篇文章《构建基于 Rust 技术栈的 GraphQL 服务(2)- 查询服务第一部分》中,介绍了构建 GraphQL Schema、整合 Tide 和 async-graphql,以及验证 query 服务。
微服务架构,这个在几年前还算比较前卫的技术在如今遍地开花。得益于开源社区的支持,我们可以轻松地利用 Spring Cloud 以及 Docker 容器化快速搭建一个微服务架构的原型。不管是成熟的互联网公司、创业公司还是个人开发者,对于微服务架构的接纳程度都相当高,微服务架构的广泛应用也自然促进了技术本身更好的发展以及更多的实践。本文将结合项目实践,剖析在微服务的背景下,如何通过前后端分离的方式开发移动应用。 对于微服务本身,我们可以参考 Martin Fowler 对 Microservice 的阐述。简单
REST(表述性状态传输)API 是一种应用程序接口 (API) 的架构风格,它使用 HTTP 请求来访问和使用数据。该数据可用于GET、PUT、POST和DELETE数据类型,指的是对资源的读取、更新、创建和删除操作。 RESTful API 使用 HTTP 方法在处理数据时执行 CRUD(创建、读取、更新和删除)过程。 为了促进缓存、AB 测试、身份验证和其他过程,标头向客户端和服务器提供信息。 主体包含客户端想要传输到服务器的数据,例如请求的有效负载。
本文的目的是提供一份快速指南 -- 《如何快速在如何在 Node.js 中创建安全的 GraphQL API》。
在 API 工艺的世界里,没有比设计更受热议的领域了。从 REST、gRPC 到 GraphQL,有许多方法可以设计和标准化 Web API 交互。今天,我们将注意力转向另一种方法,JSON API,JSONAPI.org 上详细介绍的用于构建 API 的规范。
从2023年7月起我所有可公开的文档都保存在了 GitHub Discussions 上,作为博客、IED 编辑器,以及评论使用,GitHub Discussions 是完全没问题的。
云原生(Cloud Native)Node JS Express Reactive 微服务模板 (REST/GraphQL) 这个项目提供了完整的基于 Node JS / Typescript 的微服务模板,包括生产部署、监控、调试、日志记录、安全、CI/CD 所需的所有功能。还添加了基于响应性扩展的示例,以演示如何将其用于构建微服务 API 边缘服务(edge-service)、前端的后端(BFF)或将其用作构建任何类型微服务的基础。
1. GraphQL来啦! 当Facebook构建移动应用的时候,它需要的是一个强大的数据获取API: 足够强大,满足Facebook自身复杂业务的需求; 足够简单,对开发者和使用者来说很容易上手与使
作为 Facebook 在 2015 年推出的查询语言,GraphQL 能够对 API 中的数据提供一套易于理解的完整描述,使得客户端能够更加准确的获得它需要的数据
GraphQL就是为了满足这一个需求而产生的,Facebook从2012年开始完善,与2015年展开GraphQL的开源的进程,并形成一个围绕GraphQL的社区。
技术公司采用微服务架构已经十多年了,结果好坏参半。微服务之间的依赖关系导致在修改一个服务时也需要修改其他服务,微服务的优势因此打了折扣。这就是所谓的紧密耦合。但组件之间的依赖关系是不可避免的。
在这个数字时代,我们的日常生活中充斥着各种应用程序和系统之间的交互。无论是社交媒体、在线购物还是智能家居设备,它们都需要通过API(应用程序接口)来实现数据的传输和通信。然而,这些看似简单的操作背后隐藏着复杂的协议。
我认为,GraphQL 将改变世界。将来,你可以使用 GraphQL 查询世界上的任何系统。我在创造这样的未来。那么我为什么要对使用 GraphQL 进行辩驳呢?我个人最讨厌的是,社区一直在宣传 GraphQL 的好处,而这些好处却非常普通,并且与 GraphQL 实际上没有任何关系。如果我们想推广采用,那么我们应该诚实,应该摘掉有色眼镜。这篇文章是对 Kyle Schrade 的文章“为什么使用 GraphQL”的回应。这并不是批评。这篇文章是一个很好的讨论基础,因为它代表了我在社区中经常听到的观点。如果你读了整篇文章,当然这会花一些时间,你就会完全理解,为什么我认为 Kyle 的文章应该改名为“为什么使用 Apollo”。
image.png 原文作者:Astasia Myers 原文地址:https://medium.com/memory-leak/5-microservices-trends-to-watch-in-
像其他所有人一样, 我最近碰巧也读了 Jose Aguinaga 的文章 “How it feels to learn JavaScript in 2016”.
作者 | Dane Avilla 译者 | 刘雅梦 策划 | 田晓旭 娱乐业一直在努力应对 COVID-19 对全球制作的影响冲击。自 2020 年初以来,Netflix 一直在迭代开发系统,以向内部利益相关方和企业领导者提供有关疫情最新信息的最新工具和仪表盘。这些软件解决方案使得管理层可以就给定的实体产品是否以及何时能够安全地开始在全球范围内创建引人注目的内容而做出最明智的决策。在 Netflix Studio Engineering 内部,一种备受关注的方法是将 GraphQL 微服务(GQLMS)作为
作者 | Netflix 技术博客 译者 | 刘雅梦 策划 | 蔡芳芳 借助最新的数据网格平台(Data Mesh Platform),Netflix Studio 中的数据移动进入到了一个新阶段。这种配置驱动的平台在创建新管道时显著地缩短了前置时间,同时提供了新的支持特性,比如端到端的模式演进(schema evolution)、自助式 UI 和安全数据访问等。 1背景 未来几年,Netflix 上的大部分内容都将来自其自己的工作室(Netflix Studio)。Netflix 电影或电视据从开始宣传
领取专属 10元无门槛券
手把手带您无忧上云