Хтось має досвід роботи з GraphQL та Firebase? Я вважаю, що можна було б розмістити виклики firebase у розподільнику відповідного поля, передаючи деяку змінну з реквізиту компонента в аргументи запиту.
Як ми можемо вставити нові дані у Firebase за допомогою GraphQL?
Відповіді:
Щоб відповісти на ваше запитання, ви можете впоратися з цим трьома способами .
Якщо ви налаштовані на використання Firebase, ви можете зробити індивідуальне відображення API Firebase у запити та мутації GraphQL.
Ви можете напевно обернути API Firebase у вирішувачі 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, використовуючи інше джерело даних.
Враховуючи, що ви готові використовувати такі продукти BaaS, як Firebase, ви можете перейти до використання GraphQL BaaS.
Якщо ви готові перейти на самостійне рішення за допомогою власного сховища даних, це також має багато переваг. Ось кілька великих нападників:
Гнучкість використання власного сховища даних і, можливо, декількох, відповідно до потреб конкретного додатка
Спеціальні запити та мутації
Власне додайте власну логіку замість мікросервісів, приєднаних до веб-хуків у вашому API
Створіть власні механізми автентифікації та дозволу
Ймовірно, дешевше рішення
Я категорично не погоджуюсь з деякими рекомендаціями тут. GraphQL може використовуватися в реляційному відношенні, але він також може використовуватися в режимі NoSQL. Firebase із RTD (база даних у реальному часі) та Firestore слід моделювати як базу даних NoSQL, оскільки це база даних NoSQL! Цей підхід має компроміси:
1. Оптимізоване читання:
Як база даних NoSQL, колекції повинні бути змодельовані як ваші подання у ваших клієнтах (мобільних або веб-мережах), тому, коли ви робите запит, все вже об’єднано, і вам не потрібно робити обчислюваний реквізит у клієнті та функції Firebase. Такий підхід робить читання ДІЙСНО швидким.
2. Деоптимізований запис:
Основна компромісна ситуація полягає в тому, що ви несете відповідальність за оновлення кожного документа в базі даних, якщо торкаєтесь пов’язаних даних (наприклад, оновлення імені користувача, зображення профілю тощо). У цьому випадку ви повинні знайти кожен документ у вашій базі даних (тобто: публікації, коментарі тощо) та забезпечити атомність. Цей підхід рекомендується використовувати, якщо у вас є програма, яка буде мати набагато більше операцій читання, ніж операцій запису (наприклад, блог, 7000 читає на 1 запис як приклад).
3. Легко масштабувати:
Оскільки ваші колекції не мають жорстких взаємозв’язків з іншими документами, ви можете мати повну колекцію лише на одному сервері або розділити її на багато з них. (Ось чому Firebase дешевий у масштабі, як DynamoDB.)
GraphQL - це лише мова запитів. Це має полегшити вам запит речей, але це не повинно диктувати, як ви моделюєте базу даних. Ви повинні диктувати, як змоделювати базу даних, ваші запити та мутації.
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. Поодинокі елементи даних називаються вузлами - і вузол користувача може бути підключений до багатьох вузлів твіту. Ця структура даних є одночасно простою та гнучкою, крім підходу 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 :)
Ви можете використовувати graphql і firebase локально . Весь важкий підйом можна зробити у веб-співробітника, щоб уникнути блокування інтерфейсу користувача під час розв’язання запиту.
Одне слово про "безліч зворотних поїздок, необхідних для вирішення запиту": якщо ви не заперечуєте щодо переданих даних, це не така вже й велика проблема, оскільки всі "зворотні поїздки" об'єднані в одному кадрі сокета. Але якщо ви хочете уникнути великих кадрів, вам просто потрібно поставити трохи dataloaderперед своєю базою даних Firebase.
Для оновлення в режимі реального часу вам потрібно лише підписатися на події реального часу з Firebase і надіслати їх веб-співробітнику, щоб перетворити їх на реальні підписки на Graphql, які можна вирішити за допомогою вашої схеми.
Ви можете знайти більше інформації з цього питання в моєму середньому дописі: веб-додатки реального часу “Лише на стороні клієнта” з Firebase, GraphQL та apollo-client 2.0
Сподіваюся, це допоможе!
Чи потрібно використовувати firebase? Є послуги, більш специфічні для GraphQL, які можуть запропонувати те, що ви шукаєте. https://scaphold.io - це компанія зі стипендіями YC, яка виглядає особливо перспективною і надає вам досвід роботи в Firebase, але працює на GraphQL.