В чем разница между Falcor и GraphQL?

GraphQL состоит из системы типов, языка запросов и выполнения семантика, статическая валидация и интроспекция типов, каждая из которых ниже. Чтобы провести вас через каждый из этих компонентов, мы написали пример, предназначенный для иллюстрации различных частей GraphQL.

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

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

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

В чем разница между Falcor и GraphQL (в контексте Relay)?

ОТВЕТЫ

Ответ 1

Я просмотрел Angular Воздушный эпизод 26: FalcorJS и Angular 2, где Jafar Husain отвечает, как GraphQL сравнивается с FalcorJS. Это сводка (перефразирование):

  • FalcorJS и GraphQL решают одну и ту же проблему (запрос данных, управление данными).
  • Важным отличием является то, что GraphQL является языком запросов, а FalcorJS - нет.
  • Когда вы запрашиваете у FalcorJS ресурсы, вы очень четко запрашиваете конечную серию значений. FalcorJS поддерживает такие вещи, как диапазоны, например. genres[0..10]. Но он не поддерживает открытые запросы, например. genres[0..*].
  • GraphQL устанавливается на основе: дайте мне все записи, где true, порядок от этого и т.д. В этом смысле язык запросов GraphQL более мощный, чем FalcorJS.
  • С GraphQL у вас есть мощный язык запросов, но вы должны интерпретировать этот язык запросов на сервере.

Jafar утверждает, что в большинстве приложений типы запросов, которые идут от клиента к серверу, имеют одну и ту же форму. Таким образом, наличие конкретных и предсказуемых операций, таких как get и set, предоставляет больше возможностей для использования кеша. Кроме того, многие разработчики знакомы с отображением запросов с использованием простого маршрутизатора в архитектуре REST.

В конце обсуждения решается вопрос о том, превосходит ли мощность, которая приходит с GraphQL, сложность.

Ответ 2

Теперь я написал приложения с обеими библиотеками, и я могу согласиться со всем, что было в сообщении Gajus, но нашел несколько важных вещей, наиболее важных в моем собственном использовании фреймворков.

  • Вероятно, самая большая практическая разница заключается в том, что большинство примеров и, предположительно, проделанная до этого момента на GraphQL была сосредоточена на интеграции GraphQL с системой Relay - Facebook для интеграции виджетов ReactJS с их требованиями к данным. С другой стороны, FalcorJS имеет тенденцию действовать отдельно от системы виджетов, что означает, что может быть проще интегрироваться в клиент не-React/Relay и что он будет делать меньше для вас автоматически с точки зрения соответствия зависимостей данных виджета с виджетами.
  • Оборотная сторона FalcorJS, являющаяся гибкой в ​​интеграции на стороне клиента, заключается в том, что ее можно очень усомниться в том, как сервер должен действовать. У FalcorJS действительно есть возможность "вызвать этот запрос через HTTP", хотя Jafar Husain, похоже, не очень-то говорит об этом, и как только вы включите их, то, как клиентские библиотеки реагируют на информацию о сервере, весьма схожи, за исключением того, что GraphQL/Relay добавляет слой конфигурации. В FalcorJS, если вы возвращаете значение для фильма, ваше возвращаемое значение лучше сказать "фильм" , тогда как в GraphQL вы можете описать, что даже если запрос возвращает "фильм" , вы должны поместить это в хранилище данных на стороне клиента как "фильм" ". - это часть компромисса между властью и сложностью, о которой говорил Гаюс.
  • На практической основе GraphQL и Relay, по-видимому, более развиты. Jafar Husain упомянул, что следующая версия интерфейса 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, не имела официального ответа через две недели.

Ответ 3

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

Что касается отсутствия примеров, вы можете найти awesome-falcorjs repo userful, существуют различные примеры использования Falcor CRUD: https://github.com/przeor/awesome-falcorjs... Во-вторых, есть книга под названием " "Освоение разработки полного стека" включает также Falcor (хороший способ узнать, как его использовать):

введите описание изображения здесь

ORGINAL POST BELOW:

FalcorJS (https://www.facebook.com/groups/falcorjs/) гораздо проще, чем эффективнее по сравнению с Relay/GraphQL.

Кривая обучения для реле GraphQL + ОГРОМНА: введите описание изображения здесь

В своём кратком сводке: Идите на Фалькор. Используйте 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(() = > new NamesRouter()))). Источник: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/index.js

b) falcor-router - там вы определяете маршруты SIMPLE (например, route: '_view.length'). Источник: https://github.com/przeor/falcor-netflix-shopping-cart-example/blob/master/server/router.js

Falcor - кусок пирога с точки зрения кривой обучения.

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

2) Relay/GraphQL скорее всего представляет собой огромный корпоративный инструмент.

Например, у вас есть две разные документы, о которых отдельно говорят:

a) Реле: https://facebook.github.io/relay/docs/tutorial.html - Контейнеры - Маршруты - Корневой контейнер - Готовность - Мутации - Сетевой уровень - Плагин для Babel Relay - GRAPHQL

  • Спецификация реле GraphQL
  • Идентификация объекта
  • Подключение
  • Мутации
  • Дополнительная литература

  • ССЫЛКА API

  • Реле

  • RelayContainer
  • Relay.Route
  • Relay.RootContainer
  • Relay.QL
  • Relay.Mutation
  • Relay.PropTypes
  • Relay.Store

  • ИНТЕРФЕЙС

  • RelayNetworkLayer

  • RelayMutationRequest
  • RelayQueryRequest

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

  • 2Language
  • 2.1. Источник текста
  • 2.1.1Unicode
  • 2.1.2. Простое пространство
  • 2.1.3. Терминаторы
  • 2.1.4Comments
  • 2.1.5. Значимые запятые
  • 2.1.6Лекические токены
  • 2.1.7 Игнорированные токены
  • 2.1.8Punctuators
  • 2.1.9Names
  • Документ 2.2Query
  • 2.2.1Operations
  • 2.2.2Выборы выбора
  • 2.2.3Fields
  • 2.2.4Arguments
  • 2.2.5 Псевдоним поля
  • 2.2.6Fragments
  • 2.2.6.1Type Условия
  • 2.2.6.2Интерфейсные фрагменты
  • 2.2.7Введение значений
  • 2.2.7.1Int Value
  • 2.2.7.2 Значение флагов
  • 2.2.7.3Boolean Value
  • 2.2.7.4 Значение строки
  • 2.2.7.5Enum Value
  • 2.2.7.6 Значение списка
  • 2.2.7.7Введение значений объекта
  • 2.2.8Variables
  • 2.2.8.1Переменное использование внутри фрагментов
  • 2.2.9Вводные типы
  • 2.2.10Directives
  • 2.2.10.1 Директивы об устранении недостатков
  • Система 3Type
  • 3.1Types
  • 3.1.1Scalars
  • 3.1.1.1 Встроенные скаляры
  • 3.1.1.1.1Int
  • 3.1.1.1.2Float
  • 3.1.1.1.3String
  • 3.1.1.1.4Boolean
  • 3.1.1.1.5ID
  • 3.1.2Objects
  • 3.1.2.1Объектные аргументы поля
  • 3.1.2.2Объект Отклонение поля
  • 3.1.2.3 Проверка типа объекта
  • 3.1.3Interfaces
  • 3.1.3.1 Проверка подлинности типа
  • 3.1.4Unions
  • 3.1.4.1 Проверка типа подключения
  • 3.1.5Enums
  • 3.1.6Интересные объекты
  • 3.1.7Lists
  • 3.1.8Non-Null
  • 3.2Directives
  • [email protected]
  • [email protected]
  • 3.3. Типы запуска
  • 4Introspection
  • 4.1 Общие принципы
  • 4.1.1 Соглашения об именах
  • 4.1.2Documentation
  • 4.1.3Deprecation
  • 4.1.4Type Name Introspection
  • 4.2Schema Introspection
  • 4.2.1 Тип "__Type"
  • 4.2.2 Типы типов
  • 4.2.2.1Scalar
  • 4.2.2.2Object
  • 4.2.2.3Union
  • 4.2.2.4Interface
  • 4.2.2.5Enum
  • 4.2.2.6Возвращаемый объект
  • 4.2.2.7List
  • 4.2.2.8Non-нуль
  • 4.2.2.9Соединение списка и не нуль
  • 4.2.3 Тип __Field
  • 4.2.4 Тип __InputValue
  • 5Validation
  • 5.1Operations
  • 5.1.1Именованные определения операций
  • 5.1.1.1Описание Название Уникальность
  • 5.1.2. Определения анонимной работы
  • 5.1.2.1Некоторые анонимные действия
  • 5.2Fields
  • 5.2.1. Выбор полей для типов объектов, интерфейсов и союзов.
  • 5.2.2. Слияние полей.
  • 5.2.3. Полевые выборки
  • 5.3Arguments
  • 5.3.1Имя имен
  • 5.3.2 Уникальность действия
  • 5.3.3. Правильность значений значений аргументов
  • 5.3.3.1 Совместимые значения
  • 5.3.3.2 Необходимые аргументы
  • 5.4Fragments
  • 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.5Values ​​
  • 5.5.1 Уникальная уникальность поля объекта
  • 5.6Directives
  • 5.6.1 Определены директивы
  • 5.7Variables
  • 5.7.1Variable Uniquity
  • 5.7.2Вводимые значения по умолчанию правильны.
  • 5.7.3Variables - это типы ввода.
  • 5.7.4Все переменная использует определенные
  • 5.7.5Все используемые переменные
  • 5.7.6 Разрешено использование переменных переменных
  • 6Execution
  • 6.1Оценка запросов
  • 6.2Переключающие переменные
  • 6.3Оценка операций
  • 6.4Оценка выбора наборов
  • 6.5Оценка набора сгруппированных полей
  • 6.5.1. Записи входа
  • 6.5.2Ночная оценка
  • 6.5.3Серверное выполнение
  • 6.5.4 Обработка ошибок
  • 6.5.5Nullability
  • 7Response
  • 7.1Serialization Format
  • 7.1.1JSON Сериализация
  • 7.2Отчетный формат
  • 7.2.1Data​​li >
  • 7.2.2Errors
  • AAppendix: условные обозначения
  • A.1 Неконтекстная грамматика
  • A.2Легическая и синтаксическая грамматика
  • A.3Грамматическая нотация
  • A.4. Семантика грамматики
  • A.5Algorithms
  • BAppendix: Краткое описание грамматики
  • B.1Ignored Tokens
  • B.2Lexical Tokens
  • Документ B.3Query

Это ваш выбор:

Простой сладкий и короткий документированный инструмент Falcor JS VERSUS с огромным уровнем корпоративного уровня с длинной и расширенной документацией как GraphQL & Relay

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

Ответ 4

Ли Байрон один из инженеров позади GraphQL сделал AMA on hashnode, вот его ответ, когда задал этот вопрос:

  • Falcor возвращает Observables, только значения GraphQL. Для того, чтобы Netflix хотел использовать Falcor, это имеет для них большой смысл. Они делают несколько запросов и представляют данные по мере готовности, но это также означает, что клиентский разработчик должен напрямую работать с Observables. GraphQL - это модель запроса/ответа и возвращает обратно JSON, который трижды легко использовать. Relay добавляет обратно в динамику, которую представляет Falcor, сохраняя при этом только простые значения.
  • Система типов. GraphQL определяется с точки зрения системы типов, что позволяет нам создавать множество интересных инструментов, таких как GraphiQL, генераторы кода, обнаружение ошибок и т.д. Falcor гораздо более динамичен, который ценен сам по себе, но ограничивает способность делать такие вещи.
  • Использование сети. GraphQL был первоначально разработан для работы с новостной лентой Facebook на устройствах с низким уровнем доступа в сетях с более низким уровнем конца, поэтому он подходит для больших целей, чтобы вы могли объявить все, что вам нужно, в одной сети чтобы минимизировать задержку. С другой стороны, Falcor часто выполняет многократные поездки для сбора дополнительных данных. Это действительно просто компромисс между простотой системы и управлением сетью. Для Netflix они также работают с очень низкими устройствами (например, Roku stick), но предположение о том, что сеть будет достаточно хороша для потокового видео.

Изменить: Falcor действительно может пакетные запросы, что делает комментарий об использовании сети неточным. Благодаря @PrzeoR

Ответ 5

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

Как они отличаются друг от друга тем, как они представляют свои данные:

  • Falcor хочет, чтобы вы считали свои данные очень большим виртуальным деревом JSON и использовали get, set и вызов для чтения, записи данные.
  • GraphQL хочет, чтобы вы считали свои данные группой предопределенных типизированных объектов и использовали запросы и мутации для чтения, записи данных.
  • Restful хочет, чтобы вы считали свои данные как группу ресурсов и использовали HTTP-глаголы для чтения, записи данных.

Всякий раз, когда нам нужно предоставлять данные для пользователя, мы получаем что-то вроде: client → query → {layer translate query to data ops} → data.

После борьбы с GraphQL, Falcor и JSON API (и даже ODdata) я написал свой собственный уровень запросов данных. Это проще, проще в освоении и более эквивалентно GraphQL.

Проверьте это:
https://github.com/giapnguyen74/nextql

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