Meteor开发指南 — 响应式GraphQL

原文来自Kadira Voice，标题为「Meteor’s Reactive GraphQL Is Just Awesome」。

Meteor正在着手开发一套响应式的GraphQL实现，他们在前几天放出了一份high-level technical documentation。这篇文章是该设计文档的总结和我对这个项目的一些想法。

这是 GraphQL

GraphQL 是一个Facebook提出的应用层的查询语言。它有许多的伴随工具和库，比如Relay，GraphiQL，和express-graphql。同时，它也有许多其它语言的实现。

如果你不知道GraphQL或者觉得它很难理解，那么可以试试这个交互式的LearnGraphQL课程。许多人都非常喜欢它。

什么是响应式 GraphQL?

首先，我们看一下下面这张图：

• 这里，客户端A使用GraphQL查询来获取数据并且渲染视图，也就是一篇博客文章。
• 客户端B在这篇文章下面发布了一条评论。
• 那条评论会自动推送到客户端A。应用的开发者不需要写任何显式的代码来获取那条评论。

这就是响应式GraphQL。你不必重新获取数据或是手动的重新加载网页。

基本上，它就是Meteor但是加上了GraphQL。你可以使用MongoDB，SQL数据库，REST APIs或者几乎任何其他数据源。

响应式GraphQL开发体验

大多数的繁重工作已经被响应式GraphQL库和工具完成了。所以，你只需要简单地在服务端编写GraphQL的数据模式，在客户端编写查询即可。

以下是一个典型的开发体验：

• 你在服务端写了GraphQL的数据模式，并且使用特定的数据库驱动来从数据库获取数据。
• 你可以按需使用你自己的数据源。
• 在客户端，你可以像平常使用GraphQL那样创建查询和调用修改。
• 为此，你需要使用一个客户端库响应式GraphQL。（它在背后使用Relay作为缓存处理了所有响应式的东西）

就这么简单。现在，你的所有GraphQL请求都是响应式的，并且你的客户端app总是有依照数据模式的最近的数据。

部署和扩展App

部署一个响应式的GraphQL应用也非常简单。仅仅部署它，并且扩展至足够的容器（或服务器）中。服务端app只是一个有着响应式GraphQL数据库驱动的express-graphql。

所以你只需要按照普通Node.js的应用部署和扩展方式进行处理。

听起来不错！那么它在哪儿处理响应式呢？

好问题。你的应用服务器并不知道响应式或如何验证错误查询。它仅仅暴露一些GraphQL的数据模式。

响应式由另一个服务器处理，也被称作失效服务器。

失效服务器

这是一个轻量级服务器，用来追踪所有通过GraphQL数据模式发送到客户端的文档版本。你的应用服务器发送所有查询请求和修改到这个服务器上。

你的应用客户端会与这个失效服务器交流并且观察所有的失效记录。如果有失效记录的话，它会从GraphQL应用服务器获取数据。（失效服务器会判断旧版本是否失效，返回新版本的数据）

整个流程如此设计，所以维持了使用的方便性并且没有牺牲性能。了解更多信息，请参见Design documentation。

这个失效服务器并不真的处理数据。通常它对数据一无所知。你可以把它理解成一个分布式的版本跟踪服务。

Meteor的计划是把失效服务器作为一个开源项目，并且隶属于响应式GraphQL项目。

很有可能Galaxy (Meteor’s hosting service)会提供一个托管的失效服务器供你的app使用。所以，你不必担心你的服务端了。

视图层：React, Angular, Blaze, etc.

GraphQL通常与基于React和Relay的应用联合使用。但是响应式的GraphQL却是独立于视图层的。在客户端，它仅仅是一个响应式数据源。你可以将它和任何的视图层相结合。无论是Angular，React，Blaze还是其他没有实现的框架。

如果你需要一个示例，请参考Lokka。它是一个简单的GraphQL JavaScript客户端。客户端响应式GraphQL会和Lokka相似，但是有了响应式的种种好处。

更多信息

这篇文章仅仅简要介绍了一下响应式GraphQL。这个项目仍处于设计阶段。你可以查看下面这些文档获取更多信息。

Reactive GraphQL: High Level Design

这篇文章简明易懂，你可以看看其下的讨论。

参考

• Meteor’s Reactive GraphQL Is Just Awesome
• High-level design