Чим відрізняється Falcor від GraphQL?

GraphQL складається з системи типів, мови запитів та семантики виконання, статичної перевірки та самоаналізу типу, кожен з яких викладений нижче. Щоб провести вас через кожен з цих компонентів, ми написали приклад, призначений для ілюстрації різних фрагментів GraphQL.

- https://github.com/facebook/graphql

Falcor дозволяє представляти всі віддалені джерела даних у вигляді єдиної моделі домену через віртуальний графік JSON. Ви кодуєте так само, незалежно від того, де перебувають дані, чи в пам'яті на клієнті, так і по мережі на сервері.

- http://netflix.github.io/falcor/

Чим відрізняється Falcor від GraphQL (в контексті реле)?

Я переглянув Angular Air Episode 26: FalcorJS і Angular 2, де Джафар Хусейн відповідає, як GraphQL порівнює з FalcorJS . Це резюме (перефразовування):

• FalcorJS і GraphQL вирішують одну і ту ж проблему (запити даних, управління даними).
• Важливою відмінністю є те, що GraphQL є мовою запитів, а FalcorJS - ні.
• Коли ви запитуєте FalcorJS про ресурси, ви дуже чітко запитуєте кінцеві ряди значень. FalcorJS підтримує такі речі, як діапазони, наприклад genres[0..10]. Але він не підтримує відкриті запити, наприклад genres[0..*].
• GraphQL встановлюється на основі: дайте мені всі записи, де є правдою, впорядкуйте це тощо. У цьому сенсі мова запитів GraphQL є більш потужною, ніж FalcorJS.
• З GraphQL у вас є потужна мова запитів, але ви повинні інтерпретувати цю мову запитів на сервері.

Джафар стверджує, що в більшості програм типи запитів, що йдуть від клієнта до сервера, мають однакову форму. Тому наявність конкретних та передбачуваних операцій, таких як get and set, відкриває більше можливостей використовувати кеш-пам'ять. Крім того, багато розробників знайомі з відображенням запитів за допомогою простого маршрутизатора в архітектурі REST.

Кінцева дискусія вирішує питання про те, чи переважає потужність, яка постачається разом із GraphQL.

Зараз я написав додатки з обома бібліотеками, і я можу погодитись із усім у пості Гаджуса, але я знайшов кілька різних речей, які є найважливішими в моєму власному використанні рамок.

• Мабуть, найбільша практична відмінність полягає в тому, що більшість прикладів і, мабуть, роботи, зробленої до цього моменту на GraphQL, були зосереджені на інтеграції GraphQL з Relay - системою Facebook для інтеграції віджетів ReactJS зі своїми вимогами до даних. З іншого боку, FalcorJS має тенденцію діяти окремо від системи віджетів, що означає, що інтегруватись у клієнт, який не реагує на реагування / ретрансляцію, і що він зробить менше для вас автоматично в плані відповідності залежностей даних віджетів із віджетами, можливо, буде простіше.
• Зворотний бік FalcorJS, який є гнучким в інтеграції на стороні клієнтів, полягає в тому, що він може бути дуже впевненим у тому, як потрібно діяти серверу. FalcorJS насправді має можливість прямого "виклику цього запиту через HTTP" - хоча, здається, Jafar Husain не дуже про це говорить, - і коли ви включите їх, спосіб клієнтських бібліотек реагує на інформацію про сервер, є досить схожим, за винятком того, що GraphQL / Relay додає шар конфігурації. У FalcorJS, якщо ви повертаєте значення для фільму, ваше повернене значення краще сказати "фільм", тоді як у GraphQL ви можете описати, що навіть незважаючи на те, що запит повертає "фільм", ви повинні ставити це в сховищі даних клієнта як "фільм" '. - це частина компромісу влади проти складності, про який згадував Гаджус.
• На практичній основі, GraphQL і Relay, здається, є більш розвиненими. Джафар Хусейн згадував, що наступна версія фронтену Netflix буде запущена принаймні частково на FalcorJS, тоді як команда Facebook зазначила, що використовує деяку версію стеку GraphQL / Relay у виробництві вже понад 3 роки.
• Спільнота розробників з відкритим кодом навколо GraphQL та Relay, здається, процвітає. Існує велика кількість добре відвідуваних підтримуючих проектів навколо GraphQL та Relay, тоді як я особисто знайшов дуже мало навколо FalcorJS. Також базовий сховище github для Relay ( https://github.com/facebook/relay/pulse ) є значно більш активним, ніж сховище github для FalcorJS ( https://github.com/netflix/falcor/pulse ). Коли я вперше витягнув Facebook репо, приклади були зламані. Я відкрив випуск github, і це було вирішено протягом декількох годин. З іншого боку, випуск github, який я відкрив на FalcorJS, не отримав офіційної відповіді протягом двох тижнів.

Лі Байрон, один з інженерів GraphQL, зробив AMA на hashnode , ось його відповідь, коли йому задали це питання:

• Falcor повертає спостережувані, GraphQL просто значення. Для того, як Netflix хотів використовувати Falcor, це має для них багато сенсу. Вони роблять кілька запитів і подають дані як готові, але це також означає, що розробник клієнта повинен безпосередньо працювати з Observables. GraphQL - модель запиту / відповіді і повертає назад JSON, який тривіально простий у використанні. Реле додає деякий динамізм, який Фалькор представляє, зберігаючи лише використовуючи прості значення.
• Тип системи. GraphQL визначається з точки зору типової системи, і це дозволило нам створити безліч цікавих інструментів, таких як GraphiQL, генератори коду, виявлення помилок тощо. Falcor набагато більш динамічний, що є цінним саме по собі, але обмежує можливості робити такого роду речі.
• Використання мережі. Спочатку GraphQL був розроблений для керування новинами Facebook на пристроях низького рівня, навіть у нижчих кінцевих мережах, тому він докладає великих зусиль, щоб ви могли оголосити все необхідне в одному запиті мережі, щоб мінімізувати затримку. Falcor, з іншого боку, часто здійснює багаторазові поїздки для збору додаткових даних. Це справді лише компроміс між простотою системи та керуванням мережею. Для Netflix вони також мають справу з дуже низькими пристроями (наприклад, Roku stick), але припущення, що мережа буде досить хорошою для передачі відео.

Редагувати: Falcor дійсно може запитувати пакетні запити , що робить коментар щодо використання мережі неточним. Завдяки @PrzeoR

ОНОВЛЕННЯ. У своєму дописі я знайшов дуже корисний коментар, яким я хочу поділитися з вами як доповнення до основного вмісту:

Що стосується браку прикладів, ви можете знайти дивовижну-Falcorjs репо-користувачу, є різні приклади використання CRUD Falcor: https://github.com/przeor/awesome-falcorjs ... По-друге, є книга під назвою " Оволодіння повною стекою React Development ", що включає і Falcor (хороший спосіб навчитися ним користуватися):

ОРГІНАЛЬНІ ПОШТИ Знизу:

FalcorJS ( https://www.facebook.com/groups/falcorjs/ ) набагато простіше бути ефективним порівняно з Relay / GraphQL.

Крива навчання для GraphQL + Relay - ВЕЛИЧЕЗНА:

У моєму короткому резюме: Перейдіть на Falcor. Використовуйте Falcor у своєму наступному проекті, поки у вас не буде великий бюджет і багато часу на навчання для вашої команди, тоді використовуйте RELAY + GRAPHQL.

GraphQL + Relay має величезний API, в якому ви повинні бути ефективними. Falcor має невеликий API і його дуже легко зрозуміти будь-якому розробнику, що знайомий з JSON.

Якщо у вас є проект AGILE з обмеженими ресурсами -> тоді йдіть на FalcorJS!

МОЯ СУБЕКТИВНА думка: FalcorJS на 500% + простіше бути ефективним у повному розмірі javascript.

Я також опублікував кілька стартових наборів FalcorJS для мого проекту (+ більше прикладних проектів Falcor з повним стеком): https://www.github.com/przeor

Детальніше про технічні деталі:

1) Коли ви використовуєте Falcor, ви можете використовувати як на передньому, так і на бекенді:

імпорт falcor з 'falcor';

а потім побудуйте свою модель на основі.

... вам також потрібні дві бібліотеки, які просто використовувати у бекенді: a) falcor-express - ви використовуєте його один раз (наприклад, app.use ('/ model.json', FalcorServer.dataSourceRoute (() => новий NamesRouter ())) ). Джерело: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

б) falcor-router - там ви визначаєте ПРОСТІ маршрути (наприклад, route: '_view.length' ). Джерело: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Фалькор - це шматок пирога з точки зору кривої навчання.

Ви також можете ознайомитись з документацією, яка набагато простіша за вкладку FB, а також перегляньте статтю " чому вам слід піклуватися про falcorjs (netflix falcor) ".

2) Реле / ​​GraphQL швидше схожий на величезний інструмент підприємства.

Наприклад, у вас є дві різні документації, про які окремо йдеться:

а) Естафета: https://facebook.github.io/relay/docs/tutorial.html - Контейнери - Маршрути - Корінний контейнер - Готовий стан - Мутації - Мережевий шар - Плагін Babel Relay - GRAPHQL

• Специфікація GraphQL Relay
• Ідентифікація об'єкта
• З'єднання
• Мутації
• Подальше читання

• ПОСИЛАННЯ API

• Естафета

• RelayContainer
• Естафета.Руте
• Relay.RootContainer
• Relay.QL
• Естафета. Мутація
• Реле.PropTypes
• Естафета. Магазин

• ІНТЕРФЕЙСИ

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

б) GrapQL: https://facebook.github.io/graphql/

• 2 Язик
• 2.1 Текст джерела
• 2.1.1Унікод
• 2.1.2 Білий простір
• 2.1.3 Лінійні термінатори
• 2.1.4Коменти
• 2.1.5Нізначні коми
• 2.1.6Лексичні маркери
• 2.1.7Ігноровані токени
• 2.1.8 Пунктуатори
• 2.1.9Імена
• 2.2Довідковий документ
• 2.2.1 Операції
• 2.2.2 Набори вибору
• 2.2.3Поля
• 2.2.4 Аргументи
• 2.2.5 Польовий псевдонім
• 2.2.6Фрагменти
• 2.2.6.1Умови вводу
• 2.2.6.2 Вбудовані фрагменти
• 2.2.7Вхідні значення
• 2.2.7.1Інше значення
• 2.2.7.2 Значення пласта
• 2.2.7.3Болеве значення
• 2.2.7.4 Значення струни
• 2.2.7.5 Значення суми
• 2.2.7.6 Значення списку
• 2.2.7.7Вхідні значення об'єкта
• 2.2.8 Змінні
• 2.2.8.1 Змінне використання у фрагментах
• 2.2.9Види вводу
• 2.2.10Директиви
• 2.2.10.1 Директиви щодо фрагментів
• 3Type System
• 3.1 Типи
• 3.1.1Шкала
• 3.1.1.1 Вбудовані скаляри
• 3.1.1.1.1Інт
• 3.1.1.1.2плав
• 3.1.1.1.3Стринг
• 3.1.1.1.4Болеві
• 3.1.1.1.5ID
• 3.1.2Об’єкти
• 3.1.2.1 Аргументи об'єктного поля
• 3.1.2.2 Деструкція поля об'єкта
• 3.1.2.3 Перевірка типу об'єкта
• 3.1.3Інтерфейси
• 3.1.3.1 Перевірка типу інтерфейсу
• 3.1.4Спілки
• 3.1.4.1Перевірка типу об'єднання
• 3.1.5
• 3.1.6Вхідні об'єкти
• 3.1.7 Списки
• 3.1.8Non-Null
• 3.2Директиви
• 3.2.1@skip
• 3.2.2@include
• 3.3 Типи початку
• 4Інспекція
• 4.1Загальні принципи
• 4.1.1 Конвенції про іменування
• 4.1.2Документація
• 4.1.3Означення
• 4.1.4 Вступ Ім'я Вступ
• 4.2Сема інтроспекції
• 4.2.1Тип "__Type"
• 4.2.2 Типи видів
• 4.2.2.1Шкала
• 4.2.2.2Об’єкт
• 4.2.2.3 Союз
• 4.2.2.4Інтерфейс
• 4.2.2.5 Кількість
• 4.2.2.6Вхідний об'єкт
• 4.2.2.7Список
• 4.2.2.8 Незначне
• 4.2.2.9Спорядження, що поєднується, та ненулеве
• 4.2.3Тип поля __
• 4.2.4Тип __InputValue
• 5 Валідація
• 5.1Операції
• 5.1.1 Іменні визначення операцій
• 5.1.1.1Унікальність імені операції
• 5.1.2Анонімні визначення операцій
• 5.1.2.1Лічна анонімна операція
• 5.2Поля
• 5.2.1Поле вибору об'єктів, інтерфейсів та типів об'єднань
• 5.2.2 Об'єднання вибору поля
• 5.2.3 Вибір поля поля
• 5.3 Аргументи
• 5.3.1 Назви аргументів
• 5.3.2 Унікальність аргументу
• 5.3.3 Значення аргументу Тип Правильність
• 5.3.3.1 Сумісні значення
• 5.3.3.2 Необхідні аргументи
• 5.4Фрагменти
• 5.4.1 Фрагментні декларації
• 5.4.1.1 Унікальність імені фрагмента
• 5.4.1.2 Існування типу розповсюдження фрагмента
• 5.4.1.3 Фрагменти про складені типи
• 5.4.1.4 Фрагменти повинні бути використані
• 5.4.2 Фрагментний розкид
• 5.4.2.1. Визначена ціль розповсюдження фрагмента
• 5.4.2.2 Фрагментні спреди не повинні утворювати циклів
• 5.4.2.3 Можливе поширення фрагментів
• 5.4.2.3.1 Розподіл об'єкта в об єкті
• 5.4.2.3.2 Абстрактні розвороти в об’єкті
• 5.4.2.3.3 Розподіл об'єкта в абстрактному обсязі
• 5.4.2.3.4 Абстрактні розвороти в абстрактному масштабі
• 5.5. Цінності
• 5.5.1 Унікальність поля введення об'єкта
• 5.6Директиви
• 5.6.1 Визначено напрями
• 5.7 Змінні
• 5.7.1 Варіабельна унікальність
• 5.7.2Замінні значення за замовчуванням правильно введені
• 5.7.3 Змінні - це типи вводу
• 5.7.4Визначені всі використання змінних
• 5.7.5 Усі використані змінні
• 5.7.6 Дозволено всі зміни змінних
• 6Виконання
• 6.1Оцінка запитів
• 6.2Замінних змінних
• 6.3Оцінка операцій
• 6.4 Оцінка наборів вибору
• 6.5Оцінка згрупованого набору полів
• 6.5.1Полеві записи
• 6.5.2Нормальна оцінка
• 6.5.3 Повітряне виконання
• 6.5.4 Поводження з помилками
• 6.5.5 Зменшення
• 7Відповідь
• 7.1 Формат серіалізації
• 7.1.1 JSON серіалізація
• 7.2Формат відповіді
• 7.2.1 Дані
• 7.2.2 Помилки
• AA Додаток: Конвенції про позначення
• A.1 Граматика без контексту
• A.2Лексична та синтаксична граматика
• A.3 Граматичні позначення
• A.4 Граматична семантика
• A.5Альгоритми
• BA Додаток: Підсумки граматики
• B.1 Проігноровані маркери
• B.2Лексичні маркери
• B.3Довідковий документ

Це твій вибір:

Простий солодкий і короткий задокументований Falcor JS VERSUS Величезний інструмент для підприємств з довгою та вдосконаленою документацією як GraphQL & Relay

Як я вже говорив раніше, якщо ви передовий розробник, який розуміє ідею використання JSON, то реалізація графіків JSON від команди Falcor - найкращий спосіб зробити ваш повнорозмірний проект розробників.

Коротше кажучи, Falcor або GraphQL або Restful вирішують ту саму проблему - надають інструмент для ефективного запиту / маніпулювання даними.

Як вони відрізняються, полягає в тому, як вони представляють свої дані:

• Falcor хоче, щоб ви вважали їхні дані дуже великим віртуальним деревом JSON, і використовує функції отримання , встановлення та виклику для читання, запису даних.
• GraphQL хоче, щоб ви вважали їхні дані як групу заздалегідь визначених об'єктів, і використовує запити та мутації для читання, запису даних.
• Відпочиваючий хоче, щоб ви вважали їхні дані групою ресурсів, і використовує дієслова HTTP для читання, запису даних.

Щоразу, коли нам потрібно надати дані для користувача, ми закінчуємо чимось подобається: client -> query -> {шар перекладає запит у data ops} -> data.

Після боротьби з API GraphQL, Falcor та JSON (і навіть ODdata) я написав власний рівень запиту даних . Це простіше, простіше в навчанні та еквівалентніше GraphQL.

Перевірте це за адресою:
https://github.com/giapnguyen74/nextql

Він також інтегрується з featherjs для запиту / мутації в реальному часі. https://github.com/giapnguyen74/nextql-feathers

Добре, просто почніть з простої, але важливої ​​різниці, GraphQL - це час, який базується на запитах Falcor - ні!

Але як вони допомагають u?

В основному вони обидва допомагають нам керувати і запитувати дані, але GraphQL має модель req / res і повертає дані як JSON , в основному ідея в GraphQL має єдиний запит отримати всі ваші дані в одну мету ... Крім того, мати точну відповідь, маючи точний запит, тож щось запустити на низькошвидкісному Інтернеті та мобільних пристроях, як-от мережі 3G ... Тож якщо у вас багато користувачів мобільних пристроїв або з якихось причин ви хочете мати менше запитів і швидшу відповідь , використовуйте GraphQL ... Хоча Faclor не дуже далеко від цього, тому читайте далі ...

З іншого боку, Falcor від Netflix, як правило, мають додатковий запит (як правило, не один раз), щоб отримати всі ваші дані, навіть якщо вони намагаються вдосконалити його до одного запиту ... Falcor більш обмежений для запитів і не має попереднього -визначені помічники запитів, такі як діапазон і т.д. ...

Але для більш детального роз'яснення давайте подивимось, як кожен із них представиться:

GraphQL, мова запитів для вашого API

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

Надішліть запит GraphQL до свого API і отримайте саме те, що вам потрібно, нічого більше і нічого менше. Графічні запити завжди повертають передбачувані результати. Програми, що використовують GraphQL, є швидкими та стабільними, оскільки вони керують отриманими даними, а не сервером.

GraphQL-запити отримують доступ не лише до властивостей одного ресурсу, але й плавно слідують за посиланнями між ними. У той час як типові API REST вимагають завантаження з декількох URL-адрес, API GraphQL отримують усі дані, які потрібні вашій програмі в одному запиті. Програми, що використовують GraphQL, можуть бути швидкими навіть у повільних мобільних мережних з'єднаннях.

API API API для GraphQL організовані у вигляді типів та полів, а не кінцевих точок. Отримайте доступ до всіх можливостей ваших даних з однієї кінцевої точки. GraphQL використовує типи, щоб додатки запитували лише те, що можливо, і забезпечували явні та корисні помилки. Програми можуть використовувати типи, щоб уникнути написання коду для ручного розбору.

Falcor, бібліотека JavaScript для ефективного отримання даних

Falcor дозволяє представляти всі віддалені джерела даних у вигляді єдиної моделі домену через віртуальний графік JSON. Ви кодуєте так само, незалежно від того, де перебувають дані, чи в пам'яті на клієнті, так і по мережі на сервері.

Синтаксис шляху, схожий на JavaScript, дозволяє легко отримати доступ до стільки чи мало даних, коли ви хочете. Ви отримуєте свої дані за допомогою звичних операцій JavaScript, таких як отримання, встановлення та виклик. Якщо ви знаєте свої дані, ви знаєте свій API.

Falcor автоматично перебирає посилання у вашому графіку та робить запити за потребою. Falcor прозоро обробляє всі мережеві комунікації, умовно-контрольно використовуючи пакетні та видалені запити.