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

Ответ 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