80

有人对 GraphQL 和 Firebase 有任何经验吗？我认为可以将 firebase 调用放在相关字段的解析器中，将一些变量从组件的 props 传递到查询的参数中。

我们如何使用 GraphQL 在 Firebase 中插入新数据？

4

5 回答 5

59

要回答您的问题，您可以通过三种方式来解决这个问题。

1. Firebase 和 GraphQL

如果您准备使用 Firebase，您可以将 Firebase 的 API 一对一映射到 GraphQL 查询和突变。

您当然可以将 Firebase API 包装到 GraphQL 解析器中，并以这种方式进行调用。这是一个很好的例子：

const ref = path => firebase.database().ref(path)
const getValue = path => ref(path).once('value')
const mapSnapshotToEntities = snapshot => snapshot.val().map((value, id) => ({ id, ...value }))
const getEntities = path => getValue(path).then(mapSnapshotToEntities)

const resolvers = {
    Author: {
        posts(author) {
            return getEntities('posts').then(posts => filter(posts, { authorId: author.id }))
        },
    },

    Post: {
        author(post) {
            return getEntities('authors').then(posts => filter(authors, { id: authorId }))
        },
    },
};

本质上，您在这里所做的是使用 Firebase 作为数据库，直到您想在 resolvers 中以关系方式查询数据为止。如果无法在数据存储顶部的服务器端执行连接，您将在解析器中向 Firebase 发出大量往返请求，以完成一个请求。

大多数人使用 Firebase 的原因是它的实时功能，而不仅仅是作为数据存储，因为这方面的数据关系建模工具相当缺乏。有了这个，您最好使用不同的数据源迁移到 GraphQL。

2. GraphQL 后端即服务

考虑到您愿意使用 Firebase 等 BaaS 产品，您可能会考虑切换到 GraphQL BaaS。

3. 自托管 GraphQL

如果您愿意使用自己的数据存储转换为自托管解决方案，那么这样做也有很多好处。这里有几个大人物：

  • 使用您自己的数据存储的灵活性，可能还有多种数据存储以满足您特定应用程序的需求

  • 自定义查询和突变

  • 本地添加自定义逻辑，而不是通过附加到 API 中的 webhook 的微服务

  • 滚动您自己的身份验证和许可机制

  • 可能是一种低成本的解决方案

于 2017-04-24T17:02:36.027 回答
19

我强烈不同意这里的一些建议。GraphQL 可以以关系方式使用，但也可以以 NoSQL 方式使用。Firebase 及其 RTD（实时数据库）和 Firestore，应该建模为 NoSQL 数据库，因为它是 NoSQL 数据库！这种方法需要权衡取舍：

1.优化阅读：

作为 NoSQL 数据库，集合应该建模为您在客户端（移动或网络）中的视图，因此当您进行查询时，所有内容都已合并，您不必在客户端或 Firebase 函数中创建计算道具。这种方法使阅读真的非常快。

2.去优化写：

这里的主要权衡是，如果您触摸相关数据（如更新用户名、个人资料图片等），您有责任更新数据库中的每个文档。在这种情况下，您应该找到数据库中的每个文档（即：帖子、评论等）并确保原子性。如果您的应用程序的读取操作远多于写入操作（例如博客，以 7000 次读取到 1 次写入为例），则建议使用此方法。

3. 易于扩展：

由于您的集合与其他文档没有硬性关系，因此您可以仅在一台服务器中拥有完整的集合，也可以将其拆分到多个服务器中。（这就是为什么 Firebase 的扩展成本很低，比如 DynamoDB。）

GraphQL 只是一种查询语言。它应该使您可以轻松查询事物，但它不应该决定您如何为数据库建模。您应该指定如何对数据库、查询和突变进行建模。

于 2018-05-27T05:33:55.300 回答
16

TL;DR： GraphQL 在 Firebase 的不足之处大放异彩。强大的数据建模、灵活高效的查询和开放的规范都是 GraphQL 的重要组成部分，而 Firebase 所缺乏的。

强大的数据建模

Firebase 由于其有限的数据建模而受到了很多批评。基本上，您的数据结构为单个巨大的 JSON，它多次声明相同的数据。当您需要更新数据时，一开始看起来很方便的做法会导致客户端代码无法管理，因为您必须手动跟踪对相同数据的所有引用。

另一方面，GraphQL 中使用的数据结构非常直观且易于思考，因为它被建模为图形。使用IDL 语法，我们可以轻松地描述我们的数据模型，称为 GraphQL 模式。对于 Twitter 应用程序，架构可能如下所示：

type Tweet {
  id: ID!
  title: String!
  author: User! @relation(name: "Tweets")
}

type User {
  id: ID!
  name: String!
  tweets: [Tweet!]! @relation(name: "Tweets")
}

在这里，我们定义了两种类型Tweet，并User具有一些标量属性以及 和之间的一对多关系。单个数据项被称为节点——一个用户节点可以连接到许多推文节点。这种数据结构既简单又灵活，不同于 Firebase 的 JSON 方法。UserTweet

灵活高效的查询

GraphQL 灵活的查询能力是其主要优势之一。查询是分层的，这意味着您可以指定反映图形结构的数据要求。在我们的 Twitter 示例中，我们可能有一个查询来获取所有用户及其推文：

query {
  allUsers {
    id
    name
    tweets {
      title
    }
  }
}

请注意，我们可以自由地包含或省略要查询的字段，甚至可以跨关系进行查询。这意味着我们既不需要执行多个查询，也不需要查询不需要的数据——这使得 GraphQL 查询非常高效。

将查询参数添加到组合中，我们可以添加自定义订单或过滤器等功能，以获得强大的 GraphQL API。

Firebase 根本无法实现所有这些。

实时数据

Firebase 的实时功能使其如此受欢迎 - 但由于 GraphQL 社区即将就 realtime 达成共识，Firebase 的最大优势也被取消了。我推荐这个关于 GraphQL 订阅的视频教程，以更好地理解底层概念

结论

因此，回答您的问题：GraphQL 在大多数方面都超过了 Firebase，使其成为首选。

如果您对 GraphQL 感兴趣，我建议您查看Graphcool，它结合了 GraphQL 的优势和强大的功能，例如内置身份验证和AWS Lambda的灵活挂钩或其他无服务器功能，以实现自定义业务逻辑。

免责声明：我在 Graphcool 工作 :)

于 2017-03-21T12:45:28.167 回答
7

您可以在本地使用 graphql 和 firebase。所有繁重的工作都可以在 webworker 中完成，以避免在解析请求时阻塞 UI。

关于“解决请求所需的许多往返”的一句话：如果您不介意传输的数据，那没什么大不了的，因为所有“往返”都合并在同一个套接字框架中。但是如果你确实想避免大框架，你只需要dataloader在你的 firebase 数据库前面放一点。

对于实时更新，您只需从 firebase 订阅实时事件并将它们发送给 webworker 以将它们转换为可以通过您的模式解决的真正的 graphql 订阅。

你可以在我的中篇文章中找到关于这个问题的更多信息：“Client-side only” realtime web applications with Firebase, GraphQL and apollo-client 2.0

希望有帮助！

于 2017-09-26T12:43:10.517 回答
6

你必须使用firebase吗？有一些更特定于 GraphQL 的服务可能会提供您正在寻找的内容。https://scaphold.io是一家 YC Fellowship 公司，看起来特别有前途，可以为您提供类似火力的体验，但它由 GraphQL 提供支持。

于 2016-06-01T19:51:54.093 回答