Ответ 1

Чтобы ответить на ваш вопрос, есть тремя способами, с которыми вы можете справиться.

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 в качестве базы данных, которая работает до тех пор, пока вы не захотите запрашивать ваши данные в реляционных резольверах. Без возможности выполнения объединений на стороне сервера поверх хранилища данных вы будете отправлять тонны двусторонних запросов в Firebase в ваших резольверах для выполнения всего одного запроса.

Причина, по которой большинство людей используют Firebase, заключается в его возможностях в реальном времени, а не в основном в качестве хранилища данных, поскольку в этом аспекте инструментов реляционного моделирования данных не хватает. При этом вам, вероятно, лучше перейти на GraphQL с использованием другого источника данных.

2. Серверная часть GraphQL как сервис

Учитывая, что вы открыты для использования продуктов BaaS, таких как Firebase, вы можете перейти на GraphQL BaaS.

3. Самостоятельно размещенный GraphQL

Если вы готовы перейти на автономное решение, использующее собственное хранилище данных, у этого также есть много преимуществ. Вот несколько крупных нападающих:

• Гибкость использования собственного хранилища данных и, возможно, нескольких, чтобы удовлетворить ваши конкретные потребности приложения

• Пользовательские запросы и мутации

• Собственно добавляйте пользовательскую логику вместо микросервисов, подключенных к веб-крючкам в вашем API

• Сверните свои собственные механизмы аутентификации и разрешения

• Вероятно, более дешевое решение

Ответ 2

Я категорически не согласен с некоторыми рекомендациями здесь. GraphQL можно использовать реляционным способом, но также можно использовать и способом NoSQL. Firebase, с его RTD (базой данных реального времени) и Firestore, должен быть смоделирован как база данных NoSQL, потому что это база данных NoSQL! У этого подхода есть свои недостатки:

1. Оптимизировано чтение:

Как база данных NoSQL, коллекции должны быть смоделированы как ваши представления в ваших клиентах (мобильных или в Интернете), поэтому, когда вы делаете запрос, все уже объединено, и вам не нужно делать вычисленные реквизиты в клиенте или функции Firebase. Такой подход делает чтение действительно ДЕЙСТВИТЕЛЬНО быстрым.

2. Де-оптимизированная запись:

Основной компромисс здесь заключается в том, что вы несете ответственность за обновление каждого документа в базе данных, если вы касаетесь связанных данных (таких как обновление имени пользователя, изображения профиля и т.д.). В этом случае вы должны найти каждый документ в вашей базе данных (т.е. посты, комментарии и т.д.) И обеспечить атомарность. Этот подход рекомендуется, если у вас есть приложение, которое будет иметь гораздо больше операций чтения, чем операций записи (например, блог, 7000 операций чтения на 1 запись в качестве примера).

3. Легко масштабируется:

Поскольку ваши коллекции не имеют жестких отношений с другими документами, вы можете иметь полную коллекцию только на одном сервере или разделить ее среди многих из них. (Вот почему Firebase дешев в масштабировании, как DynamoDB.)

GraphQL - это только язык запросов. Это должно упростить вам запросы, но не должно диктовать, как вы смоделируете свою базу данных. Вы должны диктовать, как моделировать вашу базу данных, ваши запросы и мутации.

Ответ 3

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 с некоторыми скалярными свойствами, а также отношение "один ко многим" между User и Tweet. Единые элементы данных называются узлами - и пользователь node может быть подключен ко многим узлам твитов. Эта структура данных является простой и гибкой, за исключением подхода JSON от Firebase.

Гибкие и эффективные запросы

Гибкие возможности запросов GraphQL являются одним из его основных преимуществ. Запросы являются иерархическими, это означает, что вы можете указать требования к данным, которые отражают структуру графика. В нашем примере Twitter мы можем запросить всех пользователей и их твитов:

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

Обратите внимание, что мы можем свободно включать или оставлять поля, которые мы хотим запросить, и мы можем даже запрашивать отношения. Это означает, что нам не нужно делать несколько запросов и мы не запрашиваем ненужные данные, что делает запросы GraphQL чрезвычайно эффективными.

Добавляя аргументы запроса к смешению, мы можем добавить такие функции, как пользовательский порядок или фильтры, чтобы получить мощный API-интерфейс GraphQL.

Все это просто невозможно с Firebase.

Данные в реальном времени

Возможности реального времени Firebase сделали его настолько популярным, но поскольку сообщество GraphQL собирается достичь консенсуса относительно реального времени, максимальное преимущество Firebase сводится к нулю также. Я рекомендую этот видеоурок о подписках GraphQL, чтобы лучше понять базовые понятия

Заключение

Итак, чтобы ответить на ваш вопрос: GraphQL превосходит Firebases в большинстве аспектов, делая его предпочтительным выбором.

Если вы заинтересованы в GraphQL, я рекомендую вам проверить Graphcool, который сочетает в себе сильные стороны GraphQL с такими мощными функциями, как встроенный аутентификации и гибких привязок к AWS Lambda или другим безсерверным функциям для реализации пользовательской бизнес-логики.

Отказ от ответственности: я работаю в Graphcool:)

Ответ 4

Вам нужно использовать firebase? Существуют более специфичные для GraphQL службы, которые могут предложить то, что вы ищете. https://scaphold.io - это компания YC Fellowship, которая выглядит особенно многообещающей и дает вам опыт работы с firebase, но на нем работает GraphQL.

Ответ 5

Вы можете использовать graphql & пожарная база локально. Все тяжелые работы могут быть выполнены веб-работником, чтобы избежать блокировки пользовательского интерфейса при разрешении запроса.

Одно слово о "множестве циклических переходов, необходимых для разрешения запроса": если вы не возражаете против передаваемых данных, это не так уж важно, поскольку все "циклические переходы" объединены в одном кадре сокета. Но если вы хотите избежать больших фреймов, вам просто нужно поместить небольшой dataloader перед вашей базой данных Firebase.

Для обновлений в реальном времени вам нужно только подписаться на события в реальном времени из firebase и отправить их веб-работнику, чтобы преобразовать их в реальные подписки graphql, которые можно разрешить с помощью вашей схемы.

Более подробную информацию по этой проблеме вы можете найти в моем среднем посте: веб-приложения реального времени "только на стороне клиента" с Firebase, GraphQL и apollo-client 2.0

Надеюсь, это поможет !