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

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

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

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

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

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

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

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

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

Окончательное обсуждение решает, перевешивает ли сила, которая приходит с GraphQL, сложность.

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

• Вероятно, самое большое практическое отличие состоит в том, что большинство примеров и предположительно работа, проделанная до этого момента над GraphQL, была сосредоточена на интеграции GraphQL с Relay - системой Facebook для интеграции виджетов ReactJS с их требованиями к данным. FalcorJS, с другой стороны, имеет тенденцию действовать отдельно от системы виджетов, что означает, что может быть легче интегрироваться в не-React / Relay-клиент и что он будет делать меньше для вас автоматически с точки зрения соответствия зависимостей данных виджетов с виджетами.
• С другой стороны, гибкость FalcorJS в интеграции на стороне клиента заключается в том, что он может быть очень самоуверенным относительно того, как должен действовать сервер. FalcorJS на самом деле имеет прямую возможность «Call this Query over HTTP» - хотя Джафар Хусейн, кажется, не слишком много об этом говорит - и как только вы включите их, то, как клиентские библиотеки реагируют на информацию о сервере, очень похоже, за исключением того, что 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, не получила официального ответа в течение двух недель.

Ли Байрон (Lee Byron), один из разработчиков GraphQL, сделал AMA для hashnode , вот его ответ на вопрос:

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

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

ОБНОВЛЕНИЕ: Я нашел очень полезный комментарий в своем посте, которым я хочу поделиться с вами как дополнение к основному содержанию:

Что касается отсутствия примеров, вы можете найти репозиторий awesome-falcorjs полезным, есть различные примеры использования CRUD Falcor: https://github.com/przeor/awesome-falcorjs ... Во-вторых, есть книга под названием " Освоение разработки полного стека React ", в которую также входит 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, вы можете использовать как на переднем конце, так и на бэкенде:

импортировать сокол от «сокол»;

а затем построить свою модель на основе.

... вам также нужны две библиотеки, которые просты в использовании на сервере: 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

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

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

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

2) Relay / GraphQL скорее похож на огромный корпоративный инструмент.

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

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

• GraphQL Relay Спецификация
• Идентификация объекта
• соединение
• Мутации
• Дальнейшее чтение

• API ССЫЛКА

• Реле

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

• ИНТЕРФЕЙС

• RelayNetworkLayer

• RelayMutationRequest
• RelayQueryRequest

б) 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.2 Запрос документа
• 2.2.1Operations
• 2.2.2 Наборы выбора
• 2.2.3Fields
• 2.2.4Arguments
• 2.2.5 Псевдоним поля
• 2.2.6Fragments
• 2.2.6.1Типовые условия
• 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.5 Значение Enum
• 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 Фрагмент Директивы
• 3Тип Система
• 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
• 3.2.1@skip
• 3.2.2@include
• 3.3Начальные типы
• 4Introspection
• 4.1Общие принципы
• 4.1.1 Соглашения об именах
• 4.1.2Documentation
• 4.1.3Deprecation
• 4.1.4. Самоанализ имени типа
• 4.2Схема самоанализ
• 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.1 Переменная Уникальность
• 5.7.2 Переменные значения по умолчанию правильно набраны
• 5.7.3 Переменные являются типами ввода
• 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.1Сериализация Формат
• 7.1.1JSON Сериализация
• 7.2 Формат ответа
• 7.2.1Data
• 7.2.2Errors
• AAppendix: условные обозначения
• A.1Контекстная грамматика
• A.2Лексическая и синтаксическая грамматика
• A.3 Грамматическая нотация
• A.4 Грамматическая семантика
• A.5Algorithms
• BAppendix: Грамматическое Резюме
• B.1 Игнорируемые токены
• B.2Лексические токены
• B.3 Запросный документ

Это твой выбор:

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

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

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

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

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

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

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

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

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

Хорошо, просто начните с простого, но важного различия: GraphQL основан на запросах, тогда как Falcor нет!

Но как они тебе помогают?

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

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

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

GraphQL, язык запросов для вашего API

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

Отправьте запрос GraphQL своему API и получите именно то, что вам нужно, не больше и не меньше. Запросы GraphQL всегда возвращают предсказуемые результаты. Приложения, использующие GraphQL, быстры и стабильны, потому что они контролируют данные, которые они получают, а не сервер.

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

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

Falcor, библиотека JavaScript для эффективного извлечения данных

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

JavaScript-подобный синтаксис пути позволяет легко получить доступ к большому или меньшему количеству данных, когда вы этого хотите. Вы извлекаете свои данные, используя знакомые операции JavaScript, такие как get, set и call. Если вы знаете свои данные, вы знаете свой API.

Falcor автоматически просматривает ссылки на вашем графике и делает запросы по мере необходимости. Falcor прозрачно обрабатывает все сетевые коммуникации, оппортунистические запросы на пакетирование и дедупликацию.