5 回答

• 13

  要回答你的问题，有 three ways 你可以解决这个问题 .

  1. Firebase和GraphQL

  如果您已开始使用Firebase，则可以将Firebase的API一对一映射到GraphQL查询和突变中 .

  您可以将Firebase API封装到GraphQL解析器中，然后以这种方式进行调用 . This is a good example of that：

  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作为数据库， works until you want to query your data in a relational manner in your resolvers . 如果无法在数据存储顶部的服务器端执行连接，您将在解析器中向Firebase发送大量往返请求，以满足单个请求 .

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

  2. GraphQL后端即服务

  考虑到您对使用Firebase等BaaS产品持开放态度，您可能会考虑切换到GraphQL BaaS .

  3.自托管GraphQL

  如果您愿意使用自己的数据存储切换到自托管解决方案，那么也可以获得许多好处 . 以下是一些重要的打击者：

  • 使用您自己的数据存储的灵活性，也许是多个，以满足您的特定应用程序的需求

  • 自定义查询和突变

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

  • 滚动您自己的身份验证和权限机制

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

  回复于 2024-04-28T22:46:17+08:00
• 6

  TL;DR: GraphQL闪耀着Firebase不足的地方 . 强大的数据建模，灵活高效的查询和开放规范都是GraphQL的重要组成部分，Firebase缺乏这些功能 .

  强大的数据建模

  基于其有限的数据建模，Firebase受到了很多批评 . 基本上，您的数据结构为单个巨大的JSON，可以多次声明相同的数据 . 当您需要更新数据时，最初看起来很方便的是无法管理的客户端代码，因为您必须手动跟踪 all 对相同数据的引用 .

  另一方面，GraphQL中使用的数据结构非常直观且易于思考，因为它被建模为图形 . 使用IDL syntax，我们可以轻松地描述我们的数据模型，称为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 ，它们具有一些标量属性以及 User 和 Tweet 之间的一对多关系 . 单个数据项称为节点 - 用户节点可以连接到许多推文节点 . 除了Firebase的JSON方法之外，这种数据结构既简单又灵活 .

  灵活高效的查询

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

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

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

  在混合中添加查询参数，我们可以添加自定义订单或过滤器等功能以获取a powerful GraphQL API .

  Firebase完全不可能实现这一切 .

  实时数据

  Firebase的实时功能使其如此受欢迎 - 但由于GraphQL社区即将达到a consensus regarding realtime，Firebase的最大优势也无效 . 我建议在GraphQL订阅上使用this video tutorial来更好地理解底层概念

  结论

  所以，回答你的问题：GraphQL在大多数方面都超过Firebases，使其成为首选 .

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

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

  回复于 2024-04-28T22:46:17+08:00
• 6

  I strongly disagree with some recommendations here. GraphQL可以以关系方式使用，但也可以以无sql方式使用 . Firebase，它是一个无sql数据库！，这种方法有一些权衡：

  1. Optimized read:

  作为一个无sql数据库，应该将集合建模为您的客户端（移动或Web）中的视图，因此当您进行查询时，所有内容都已合并，您不必在客户端或firebase中生成计算道具功能 . 这种方法使阅读真的非常快 .

  2. De-optimized write:

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

  3. Easy to scale:

  由于您的集合与其他文档没有硬关系，您只能在一个服务器中拥有完整的集合，或者将它们分成许多服务器（这就是为什么firebase的规模很便宜，比如dynamoDB） .

  GraphQL只是一种查询语言，它应该可以让您轻松查询内容，但它不应该规定您如何为数据库建模，您应该规定如何建模数据库，查询和突变 .

  回复于 2024-04-28T22:46:17+08:00
• 9

  你必须使用firebase吗？有一些针对GraphQL的服务可能会提供您正在寻找的服务 . https://scaphold.io是YC奖学金公司，看起来特别有前途，并为您提供类似体验的火力棒，但它由GraphQL提供支持 .

  回复于 2024-04-28T22:46:17+08:00
• 42

  You can use graphql & firebase locally . 所有繁重的工作都可以在webworker中完成，以避免在解析请求时阻止UI .

  关于"many roundtrips necessary to resolve the request"的一句话：如果你因为所有的"roundtrips"合并在同一个套接字框架中而没有那么重要 . 但是如果你想避免使用大帧，你只需要在你的firebase数据库前加一点 dataloader .

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

  您可以在我的中文帖子上找到有关此问题的更多信息：“Client-side only” realtime web applications with Firebase, GraphQL and apollo-client 2.0

  希望有所帮助！

  回复于 2024-04-28T22:46:17+08:00