Facebook открыл (https://code.facebook.com/posts/1691455094417024/graphql-a-d.../) свои наработки, связанные с языком формирования запросов GraphQL (http://graphql.org/), предоставляющий API для эффективного получения данных. GraphQL сочетает высокую гибкость, достаточную для описания всех потоков данных в Facebook, с простотой для изучения, способствующей быстрому внедрению языка в новые продукты.
Для загрузки доступен черновик спецификации GraphQL (https://github.com/facebook/graphql), эталонная реализация на языке JavaScript (https://github.com/graphql/graphql-js), библиотека (https://github.com/graphql/libgraphqlparser) с парсером для C/C++, обвязки (https://github.com/chentsulin/awesome-graphql) для различных языков программирования (Go, Ruby, Scala, Java, .Net, Python) и набор (https://github.com/graphql) сопутствующих инструментов, в том числе работающая в браузере интегрированная среда для формирования запросов graphiql (https://github.com/graphql/graphiql) и серверные компоненты для swapi (https://github.com/graphql/swapi-graphql) и express (https://github.com/graphql/express-graphql). Код открыт под лицензией BSD.
Последние несколько лет GraphQL активно используется в Facebook и служит основой для абстрагирования потоков данных для мобильных приложений для Android и iOS, позволив уйти от практики разработки мобильных приложений в виде надстройки над вариантом сайта для мобильных устройств в сторону самодостаточных программ с логикой выполнения на стороне клиента. При реализации парадигмы Model-View для получения данных отлично подходит формат JSON, но существующие методы для отправки запросов, такие, как REST и ad hoc, не отвечали требованиям Facebook и требовали выноса части логики на сторону сервера, не обладая должной универсальностью. Facebook попытался решить эту проблему в GraphQL и за последние три года перевёл все свои мобильные приложение на данную технологию.
В GraphQL состав результата запроса диктуется клиентом и содержит только необходимый набор данных - лишь то, что запросил клиент и ничего лишнего. Запрос оформляется в форме иерархического набора полей, а ответ приходит в отзеркаленном формате JSON с заполнением полей необходимыми данными. Корректность запроса обеспечивается через встроенную систему проверки типов.
<center><a href="https://fbcdn-dragon-a.akamaihd.net/hphotos-ak-xpf1/t39.2365... src="https://www.opennet.me/opennews/pics_base/0_1442302729.jpg&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>Особенности GraphQL:
- Явное задание формы данных - ответ отзеркаливает поля, указанные в запросе, что позволяет точно знать какие именно данные будут получены и какого они будут типа;
- Иерархическая организация, позволяющая отследить взаимосвязь между объектами без необходимости отправки повторных запросов и формирования сложных условий слияния, в отличие от RESTful-систем RESTful и SQL. Иерархия данных задаётся с использованием структуры в форме графа и отлично сочетается с потребностями, возникающими при построении интерфейсов пользователя;- Жесткая типизация - каждый уровень запроса GraphQL связывается (https://github.com/facebook/graphql) с определённым типом и для каждого поля декларируется свой тип (по аналогии с SQL) Такой подход позволяет выявить ошибки на этапе до выполнения запроса и даёт возможность повысить качество клиентских программ;
<font color="#461b7e">
enum Episode { NEWHOPE, EMPIRE, JEDI }interface Character {
id: String
name: String
friends: [Character]
appearsIn: [Episode]
}type Human : Character {
id: String
name: String
friends: [Character]
appearsIn: [Episode]
homePlanet: String
}
</font>
- GraphQL является лишь протоколом, не налагающим каких-либо требований к характеру хранилища. На сервере за каждое поле GraphQL отвечает определённая функция, что позволяет легко адаптировать взаимодействие с клиентами по GraphQL в имеющиеся кодовые базы, без изменения существующих схем хранения и бизнес-логики;- Независимость от версии серверного API - так как форма возвращаемых данных задаётся клиентом, серверное API может расширяться без опасности нарушения совместимости с клиентским ПО. Например, на сервере могут быть реализованы обработчики новых полей, которые будут применяться только для версий клиентов, поддерживающих эти поля, а для старых клиентов будут игнорироваться;
- Возможность получения сведений о поддерживаемых сервером данных. У сервера GraphQL можно запросить список поддерживаемых типов и получить более полные сведения о возможностях предоставляемого сервером API, без необходимости изучения кода и спецификаций.
<center><a href="https://scontent.xx.fbcdn.net/hphotos-xpf1/t39.2365-6/118913... src="https://www.opennet.me/opennews/pics_base/0_1442304015.jpg&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
URL: https://code.facebook.com/posts/1691455094417024/graphql-a-d.../
Новость: http://www.opennet.me/opennews/art.shtml?num=42964
Штука вроде годная, особенно с зеркалированием
Давно такое искал, а то с RESTful черт ногу сломит.
RESTful видимо намекает на UNREST :)
непонятно, как реализовывать поддержку таких запросов на бэкенде
Видимо примерно так https://github.com/graphql/libgraphqlparser/blob/master/pyth...
Что в слове бэкенд тебе было не понятно, что ты эту ссылку сюда впендюрил?
Все он правильно сделал (только непонятно почему только на питон, хотя доступны и другие языки).
Если вы не знаете определение слова парсер, то про бэкенд не стоит даже заикаться.
И как парсер позволит исполнить запрос? Не разобрать, а исполнить?
GraphQL - язык, а не БД, барашко. над чем ты собрался выполнять запрос?
XML был бы удобней: API можно описать схемой, по которой в клиенте легко разобрать и реализовать структуру данных.
Угу, и каждый клиент разберёт по-своему, несовместимо с остальными..
Схема вещь однозначная
JSON vs XML уже давно было. JSON победил.
Идеальный ник для этого комментария
Я невнимательно читал или оно не может в join'ы?
Объединять нужно таблицы. А у них скорее документы.
Посмотри на картинку в новости. C объединениями это выглядело-бы как то так:
"select user.id, user.name, <...> profilePicture.uri, <...>
from user, profilePicture <...>
where profilePicture.id = user.profilePictureId <...> "
Им это все не нужно.
вторая картинка, поле friends
первая картинка, поле friends
Mongo изобрели?
Пусть стандартизируют, а то без стандарта это очередной велосипед
на медиуме есть годные статьи на РУ
https://medium.com/marcius-corp/tutorial-graphql-subscriptio...
https://medium.com/marcius-corp/tutorial-graphql-server-with...
