注意：GraphQL 是 api 的查询语言，而不是数据库。从这个意义上说，它是数据库无关的， 而且可以在使用 API 的任何环境中有效使用，我们可以理解为 GraphQL 是基于 API 之上的一 层封装，目的是为了更好，更灵活的适用于业务的需求变化
GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。它由Facebook开发和开源，强烈地表达了代码即文档的期望。能够精确有效地得到数据，没有冗余。
在Koa中使用GraphQL主要有以下几步： 1. 安装 graphql、koa-graphql 和 koa-mount。 2. 引入koa-mount 和 koa-graphql。 3. 引入自定义的schema，其中定义schema又分为以下几步： (1). 定义查询字段的schema类型。 (2). 定义一个根 , 根里面定义调用schema类型的方法。 (3). 把根挂载到 GraphQLSchema。 4. 配置中间件，注意要放在实例化koa之后。 下面用代码来说明具体的实现步骤： 首先是Koa中
本文首先介绍了 GraphQL，再通过 MongoDB + graphql + graph-pack 的组合实战应用 GraphQL，详细阐述如何使用 GraphQL 来进行增删改查和数据订阅推送，并附有使用示例，边用边学印象深刻~
今天的数据驱动型企业不仅需要针对实时数据作出快速响应要，而且还必须执行复杂的查询以解决复杂的业务问题。 例如，客户个性化系统需要将历史数据集与实时数据流结合起来，以便立即向客户提供最相关的产品建议。提供关键任务的实时业务观察能力的运营分析系统也必须如此，例如，在线支付供应商需要监测其全球范围内的交易，以发现可能预示金融欺诈的异常情况。 或者想象一个网上学习平台需要为学区客户和内部客户团队提供关于学生和教师使用情况的最新洞察力。或者是一个市场新闻供应商，需要监测并确保其金融客户在狭窄的窗口内获得准确的、相关的
在Express中使用GraphQL主要有以下几步： 1. 安装 graphql 和 express-graphql。 2. 引入express-graphql。 3. 引入自定义的schema，其中定义schema又分为以下几步： (1). 定义查询字段的schema类型。 (2). 定义一个根 , 根里面定义调用schema类型的方法。 (3). 把根挂载到 GraphQLSchema。 4. 配置中间件，注意要放在实例化express之后。 下面用代码来说明具体的实现步骤： 首先是Express中的主
上一篇文章《构建基于 Rust 技术栈的 GraphQL 服务（2）- 查询服务第一部分》中，介绍了构建 GraphQL Schema、整合 Tide 和 async-graphql，以及验证 query 服务。
行文开始，先感谢几位指导的老师。相关标题和内容都已经在博客站点修改，微信公众号中就不重复推送了。
Cube是无界面商业智能平台。它帮助数据工程师和应用程序开发人员从现代数据存储中访问数据，将其组织为一致的定义，并将其交付给每个应用程序。Cube 旨在与所有支持 SQL 的数据源一起工作，包括像 Snowflake 或 Google BigQuery 这样的云数据仓库、像 Presto 或 Amazon Athena 这样的查询引擎，以及像 Postgres 这样的应用程序数据库。Cube 内置关系缓存引擎，为 API 请求提供亚秒级延迟和高并发。
在构建 Rust 异步 GraphQL 服务：基于 tide + async-graphql + mongodb（3）- 第一次重构之后，因这段时间事情较多，所以一直未着手变更服务的开发示例。现在私事稍稍告一阶段，让我们一起进行变更服务的开发，以及第二次重构。
上一篇文章中，我们对后端基础工程进行了初始化。其中，笔者选择 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 的应用开发，在此，笔者简单提及下选型理由——
什么是Spring GraphQL前沿学习部分：https://cloud.tencent.com/developer/article/1857280
本系列博客中，我们使用 Tide + async-grapqhl + mongodb + jsonwebtoken + handlebars-rust 构建基于 Rust 技术栈的 GraphQl 服务。同时，我们需要做到前后端分离。
Tide 是小型而实用的 Rust web 应用程序框架，为快速开发而构建。它提供了一组健壮的特性，使得构建异步 web 应用程序和 API 更加容易、更为有趣。
上一篇文章《crate 选择及环境搭建》中，我们对 HTTP 服务器端框架、模板引擎库、GraphQL 客户端等 crate 进行了选型，以及对开发环境进行了搭建和测试。另外，还完成了最基本的 handlebars 模板开发，这是 Rust web 开发的骨架工作。本篇文章中，我们请求 GraphQL 服务器后端提供的 API，获取 GraphQL 数据并进行解析，然后将其通过 handlebars 模板展示
在以前的构建 Rust 异步 GraphQL 服务系列中，分别采用 tide + async-graphql + mongodb 和 actix-web + async-graphql + rbatis + postgresql / mysql 开发了 GraphQL 服务后端。感兴趣的朋友可以参阅博文——
目前，web 前端开发方面，通常有两种技术组合：一种是使用模板引擎，主要在服务器端渲染，这种方式对 seo 有较高要求的应用有利；同时，在后续优化方面，也较有优势。另一种则是前端框架，如 yew、react、vue、seed 一类，采用声明式设计；在保证性能下限的前提下，高效且灵活地进行快速开发。
很久之前其实就关注过这个技术，记得当时还是React刚刚崭露头角的时期吧。总之那时候，GraphQL感觉还只是概念完备阶段，除了FB自己内部大量使用外，好像社区并不是很健全，不过大家应该都在疯狂的讨论和跟进吧。过了2年，如今再回过头来看，已经涌现出各种开源或商用服务专注于这个领域，各种语言的框架和工具也都很完备了，感觉是时候重新接触GraphQL了。如果你的项目正处于技术选型，你正在犹豫选择一种接口风格的时刻，不妨了解一下这个神奇而强大的玩意儿~~
Meteor非常出色，它开辟了实时Web开发的新时代！但是三年过去了，它也上了年纪。Meatier这个项目旨在实现同Meteor完全一样的功能，但并不采用单一而庞大的结构。本文翻译自meatier项目的README。 它牺牲了一些简洁性换取了巨大的灵活性。 下面是我对Meteor的主要抱怨： 基于Node 0.10，并且在近期不会改变 构建系统不支持代码分离（事实上完全相反，打包整个应用） 全局变量（并没有名称空间） 太依赖websockets（并不是每个页面都需要它） 不能处理CSS模块（CSS都在幕后
GraphQL 是 Facebook 开发的一种 API 的查询语言，与 2015 年公开发布，是 REST API 的替代品。
时间退回到 2012年的一个下午, 美国加利福尼亚州, facebook 的工程师们发现他们才上架没多久的移动端应用就收到了很多差评, 用户反映app响应慢，耗电严重等，经过分析后发现, 应用在第一次启动时, 会请求大量的后端api接口, 这其中包括用户自己的信息, 好友发布的内容, 以及其他的热点信息, 等等。太多的 rest api 请求, 这就是问题所在。
在 Rust 生态，使用 yew 开发 WebAssembly 应用方面，我们已经介绍了《起步及 crate 选择》、《组件和路由》，以及《资源文件及重构》。今天，我们介绍如何在 yew 开发的 wasm 前端应用中，与后端进行数据交互。我们的后端提供了 GraphQL 服务，让我们获取 GraphQL 数据并解析吧！
facebook推出的GraphQL，是一个特点非常鲜明的API查询语言。与SQL类似，GraphQL是一套规范，具体实现有很多框架。对前端而言，可以想使用SQL一样（比SQL简单且安全）可以直接获取自己所需要的数据，对于后端而言，节省了接口升级的开发成本，非常适用于快速迭代，或者多页面接口的业务。
GraphQL是facebook开源的一套数据交互方案，它并非某种具体的语言或者框架，它只是提供了一套解决方案，这套解决方案通过GraphQL规范进行定义，不同语言可以有自己的GraphQL实现，目前已经有很多语言完成了GraphQL的实现，可以在这里查看。
Egg.js 简介：https://eggjs.org/zh-cn/index.html
前段时间，笔者写了一个构建 Rust 异步 GraphQL 服务的系列博文，构建 Rust 异步 GraphQL 服务：基于 tide + async-graphql + mongodb，采用的 Rust web 框架是 Tide。
WebAssembly 相对其它 web 标准来说，稍显新颖。但 wasm 的应用范畴和方向，却十分广阔。关于其优势所在，本文不做赘述，网上有许多分析比较的文章。我们从 Rust 周报趋势来领会，可以发现 Rust 官方在 WebAssembly 上投入了不少精力。Rust 社区中，Rust + WebAssembly 的应用也比较热门，其文章和话题增长趋势显著。
前两篇文章《起步及 crate 选择》和《组件和路由》中，我们介绍了选型原因，搭建了 yew 的基本开发环境，并进行了最基础的组件和路由编码。并且和 yew 中文文档的翻译者 sansx 老师及一些感兴趣的朋友进行了友好而热烈的交流。
Rust 消除了在其他语言中流行的各种愚蠢的bug和陷阱，使开发和维护我们的项目变得更加容易。不幸的是，当涉及异步编程中常见问题时，Rust在本质上没有那么强的能力。事实上，异步编程在Rust中要比在 Javascript 中难得多.
GraphQL是Facebook提出的一种数据查询语言，核心特性是数据聚合和按需索取，目前被广泛应用于前后端之间，解决客户端灵活使用数据问题。本文介绍的是GraphQL的另一种实践，我们将GraphQL下沉至后端BFF（Backend For Frontend）层之下，结合元数据技术，实现数据和加工逻辑的按需查询和执行。这样不仅解决了后端BFF层灵活使用数据的问题，这些字段加工逻辑还可以直接复用，大幅度提升了研发的效率。
GraphQL 是一种新的 API 的查询语言，它提供了一种更高效、强大和灵活 API 查询。它 是由 Facebook 开发和开源，目前由来自世界各地的大公司和个人维护。GraphQL 对API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余。它弥补了 RESTful API(字段冗余，扩展性差、无法聚合 API、无法定义数据 类型、网络请求次数多)等不足。
Netflix 以其松耦合和高度可扩展的微服务架构而闻名，Netflix API 的后端架构经历了 4 个主要阶段。
先回到会议的主题，为什么会开这么一个会议？原本这个会议报名的时候希望可以控制到 100 人之内，不要超过 120 人，结果报到 250 人还爆满了，后来没有办法，我们只能从工作经验来筛选，选择工作经验在三年以上的比较资深的工程师，和一部分 2 年经验工作经验的，还有 5 年的，10 年甚至更久的从业者。
BFF一词来自Sam Newman的一篇博文《Pattern:Backends For Frontends》，指的是服务于前端的后端。提出这个概念的目的是为了解决什么问题呢？从大的方向来说，主要有以下两个方面：
本篇为mongodb篇，包含实例演示，mongodb高级查询，mongodb聚合管道，python交互等内容。
项目中使用的是mongodb数据库，在测试数据入库的时候，会根据源数据，然后生成一个自增的id到数据库里面，然后线上和测试环境针对同一条数据的id是不一致的。某些数据又只有id与线上匹配上的时候，才能关联上更多的数据，因此，我会去写一个脚本将同一条数据，将测试环境的id改成和线上的一致。但可能由于脚本写的还不够完善，导致数据库里面可能会写入一些重复id的记录进去，然后id又没有加唯一索引。有重复的数据又会导致正常执行etl任务会报错，因此，需要查询出在mongodb里面某个字段重复的记录。
数据库一直是在整体应用程序架构中，被吐槽的地方，比如数据库运行缓慢，数据库经常添加内存，CPU，等等，稍微懂一点程序设计，或是行业内的人士，大多都明白，没有不是的数据库，只有设计“无法无天” 的应用程序。
我们很高兴发布了Meteor 1.4，这个版本的主要更新包括了Node和MongoDB，以及更加灵活的基于社区的发布流程。1.4的发布注重平台长期的稳定性，使得我们的工作能够让Meteor和更广泛的JavaScript生态结合，并且比先前更加融入社区。 这里是一些亮点：我们更新了Node到长期支持版本4.4.7。我们同样使用了最新的MongoDB 3.2.6。这个版本的MongoDB包括了性能优异的WiredTiger存储引擎，现在默认开启。我们还引入了一个灵活的方式到Meteor核心扩展包发布流程中去。这
编者按：本文作者奇舞团前端开发工程师何文力，同时也是 W3C CSS 工作组成员。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
内容管理系统 (「CMS」) 使没有强大技术背景的人也能够轻松发布内容。我们可以使用 「CMS」 来管理我们的内容和交付。市面上有不同类型的 「CMS」，它们执行不同的目的并具有不同的功能。
是故，笔者经过 crate 比较，实践后，整合了一个笔者认为最合适的解决方案。特此分享，以求抛砖引玉。
原文来自Kadira Voice，标题为「Meteor’s Reactive GraphQL Is Just Awesome」。 Meteor正在着手开发一套响应式的GraphQL实现，他们在前几天放出了一份high-level technical documentation。这篇文章是该设计文档的总结和我对这个项目的一些想法。 这是 GraphQL GraphQL 是一个Facebook提出的应用层的查询语言。它有许多的伴随工具和库，比如Relay，GraphiQL，和express-graphql。同时
作为一名前端开发人员，GraphQL对于我们来说是令人难以置信的好用。它可以用来简化数据访问，这让我们的工作变得更加容易。
本文作者从事数据库相关工作接近四十年，最近开始使用 MongoDB。在开始使用 MongoDB 之前，作者希望有些事情自己已经知道。根据一般经验，对于数据库是什么以及它们能干什么，人们会有先入为主的认识。为了给他人提供方便，本文列出了一些常见的错误。
我从事数据库相关工作已经很长时间了，但是最近才开始使用MongoDB。在开始使用MongoDB之前，我希望有些事情我已经知道。根据一般经验，对于数据库是什么以及它们能干什么，人们会有先入为主的认识。为了给他人提供方便，本文列出了一些常见的错误。
在过去的将近半年的时间里，作者一直在使用 GraphQL 这门相对新兴的技术开发 Web 服务，与更早出现的 SOAP 和 REST 相比，GraphQL 其实提供的是一套相对完善的查询语言，而不是类似 REST 的设计规范，所以需要语言的生态提供相应的框架支持，但是由于从它开源至今也只有两三年的时间，所以在使用的过程中，尤其是在微服务架构中实践时确实还会遇到很多问题。
作者简介 工业聚，携程高级前端开发专家，react-lite, react-imvc, farrow 等开源项目作者。 兰迪咚，携程高级前端开发专家，对开发框架及前端性能优化有浓厚兴趣。 一、前言 过去两三年，携程度假前端团队一直在实践基于 GraphQL/Node.js 的 BFF (Backend for Frontend) 方案，在度假BU多端产品线中广泛落地。最终该方案不仅有效支撑前端团队面向多端开发 BFF 服务的需要，而且逐步承担更多功能，特别在性能优化等方面带来显著优势。 我们观察到有些前端
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
