Ссылка: http://graphql.org
Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

Кто-то уже ковырял? Быть может, использовал?

Здравствуйте, scf, Вы писали:

scf>Ссылка: http://graphql.org
scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>Кто-то уже ковырял? Быть может, использовал?
Давно присматриваюсь. А насколько хорошо, что клиент содержит в себе бизнес-логику? Т.е. запросы к базе по факту составляются на клиенте. Косяк! То, что они транслируются и что не напрямую — это все спецэффекты.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, scf, Вы писали:

scf>>Ссылка: http://graphql.org
scf>>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>>Кто-то уже ковырял? Быть может, использовал?
G>Давно присматриваюсь. А насколько хорошо, что клиент содержит в себе бизнес-логику? Т.е. запросы к базе по факту составляются на клиенте. Косяк! То, что они транслируются и что не напрямую — это все спецэффекты.

Я бы не был столь категоричен.

Здравствуйте, swimmers, Вы писали:

S>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, scf, Вы писали:

scf>>>Ссылка: http://graphql.org
scf>>>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>>>Кто-то уже ковырял? Быть может, использовал?
G>>Давно присматриваюсь. А насколько хорошо, что клиент содержит в себе бизнес-логику? Т.е. запросы к базе по факту составляются на клиенте. Косяк! То, что они транслируются и что не напрямую — это все спецэффекты.

S>Я бы не был столь категоричен.
Это почему же? У вас клиент формирует запросы и в случае удаления сущности из домена нужно поменять кучу кода в клиенте.

Здравствуйте, scf, Вы писали:

scf>Ссылка: http://graphql.org
scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>Кто-то уже ковырял? Быть может, использовал?

Давненько думаю найти/сделать что-то подобное, но не совсем. Описываешь в Hibernate/JPA модель данных, сбоку сам собой появляется JSON-сервис типа этого GraphQL со всеми CRUD операциями над моими сущностями. Сразу можно из DHTML клиента работать с данными, не страдая всевозможными DAO слоями/бизнес логикой на сервере. Эта бизнес логика практически всегда просто CRUD. Вопрос контроля прав доступа тоже как-то должен быть решен. Никто подобного не встречал/пробовал на практике?

16.02.2017 11:43, sr_dev пишет:
> scf>Ссылка: http://graphql.org
> scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в
> виде JSON. Интересен простым, в том числе в реализации, и мощным языком
> запросов.
>
> scf>Кто-то уже ковырял? Быть может, использовал?
>
> Давненько думаю найти/сделать что-то подобное, но не совсем. Описываешь
> в Hibernate/JPA модель данных, сбоку сам собой появляется JSON-сервис
> типа этого GraphQL со всеми CRUD операциями над моими сущностями.

Слышал про какой-то jhipster, но сам не смотрел. По описанию как раз
что-то вроде

--
WBR,
Serge.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, swimmers, Вы писали:

S>>Здравствуйте, Gattaka, Вы писали:

G>>>Здравствуйте, scf, Вы писали:

scf>>>>Ссылка: http://graphql.org
scf>>>>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>>>>Кто-то уже ковырял? Быть может, использовал?
G>>>Давно присматриваюсь. А насколько хорошо, что клиент содержит в себе бизнес-логику? Т.е. запросы к базе по факту составляются на клиенте. Косяк! То, что они транслируются и что не напрямую — это все спецэффекты.

S>>Я бы не был столь категоричен.
G>Это почему же? У вас клиент формирует запросы и в случае удаления сущности из домена нужно поменять кучу кода в клиенте.

Я не говорю, что это всегда правильно или всегда не правильно.
В каждом случае могут бы свои нюансы, связанные с производительностью, стоимостью поддержки и развития, наличия тех или иных специалистов т.д.

В примере с удалением сущности из домена, подозреваю, без переделки кучи кода все равно не обойтись.

Насколько я понимаю, это некий кусок, который открыл фейсбук и проблема именно в том, что это кусок. Нормального сервера они не дали. Текущие реализации какие-то детские, это уже не уровень фейсбука. Поэтому я пока смысла в этом не вижу. Если бы они открыли полный стек, например на Java, это было бы интересно.

Концептуально идея очень правильная. REST это очень неудобно. Но кроме концепции тут нужна и хорошая реализация, самому её написать будет сложно.

Здравствуйте, vsb, Вы писали:

vsb>Насколько я понимаю, это некий кусок, который открыл фейсбук и проблема именно в том, что это кусок. Нормального сервера они не дали. Текущие реализации какие-то детские, это уже не уровень фейсбука. Поэтому я пока смысла в этом не вижу. Если бы они открыли полный стек, например на Java, это было бы интересно.

Вы по ссылке не ходили что ли? Есть там и джава и дотнет и чё только нет!

Здравствуйте, scf, Вы писали:

scf>Ссылка: http://graphql.org
scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

Насколько я понял, это что-то схожее с ODATA. Интересно было бы увидеть нормальное сравнение.
Но сам возвращаемый формат очень похож по структуре (теми же метаданными): http://www.odata.org/documentation/odata-version-2-0/JSON-format/

Из того что не понравилось (в примерах graphql) — перевод строки в качестве разделителя полей в запросе.

Здравствуйте, Somescout, Вы писали:

S>Насколько я понял, это что-то схожее с ODATA. Интересно было бы увидеть нормальное сравнение.
Слышал, но не читал. авторство OASIS — это уже контр-рекомендация к изучению Оно стоит того?

S>Из того что не понравилось (в примерах graphql) — перевод строки в качестве разделителя полей в запросе.
В запросах пробельными символами считаются пробелы, переводы строки и запятые. т.е. можно вот так: {a b,c, d}

Здравствуйте, scf, Вы писали:

scf>Здравствуйте, Somescout, Вы писали:

S>>Насколько я понял, это что-то схожее с ODATA. Интересно было бы увидеть нормальное сравнение.
scf>Слышал, но не читал. авторство OASIS — это уже контр-рекомендация к изучению Оно стоит того?

Не знаю, тоже раздумываю над изучением всего этого — чистый REST дико надоел.

S>>Из того что не понравилось (в примерах graphql) — перевод строки в качестве разделителя полей в запросе.
scf>В запросах пробельными символами считаются пробелы, переводы строки и запятые. т.е. можно вот так: {a b,c, d}

И вот спрашивается — нафига?! Они действительно считают что разработчику захочется поиграться с разделителями — "вот здесь перевод строки, здесь запятыми отделим, а тут и пробелов хватит"? Бред какой-то.

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, vsb, Вы писали:

vsb>>Насколько я понимаю, это некий кусок, который открыл фейсбук и проблема именно в том, что это кусок. Нормального сервера они не дали. Текущие реализации какие-то детские, это уже не уровень фейсбука. Поэтому я пока смысла в этом не вижу. Если бы они открыли полный стек, например на Java, это было бы интересно.

G>Вы по ссылке не ходили что ли? Есть там и джава и дотнет и чё только нет!

Нет там ничего. Есть https://github.com/graphql-java/graphql-java но это поделка какая-то неизвестно от кого в состоянии Working Draft, expect changes, причём это клиент, а не сервер. И всё остальное такого же уровня.

Здравствуйте, vsb, Вы писали:

G>>Вы по ссылке не ходили что ли? Есть там и джава и дотнет и чё только нет!

vsb>Нет там ничего. Есть https://github.com/graphql-java/graphql-java но это поделка какая-то неизвестно от кого в состоянии Working Draft, expect changes, причём это клиент, а не сервер. И всё остальное такого же уровня.

С C# та же история. Причём почему-то ссылки на клиентские библиотеки лежат в разделе "Server".

Похоже сервер есть только на nodejs. Что довольно бесполезно.

scf>Новый
Все ясно — откладываем в сторонку, через год смотрим.

Здравствуйте, scf, Вы писали:

scf>Ссылка: http://graphql.org
scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>Кто-то уже ковырял? Быть может, использовал?

Я использовал graphql-java (это серверная часть для Java -- интерпретатор запросов и выполнение их). Предметную модель ты пишешь и пристегиваешь сам (в моем случае это был просто граф неизменяемых объектов в памяти).

GraphQL это скорее не язык запросов (как, например SQL), это скорее язык фильтрации данных. Ты предоставляешь свой унивёрсум данных, а клиент может выбрать тот кусочек, который ему интересен.

В нем есть понятие параметров, которые могут влиять на возвращаемые данные (что делает его немного похожим на язык запросов), но структура запроса прибита гвоздями (схема). Например, клиент не может произвольные куски вытаскивать или делать какие-то join-ы. Например, если твоя схема содержит поле "user" у которого есть поле "company" ты не можешь сделать запрос сразу начиная с поля "company", если его в схеме явно не задано.


Позволяет решить проблему неоптимальных запросов (N+1 или слишком большое количество данных) в REST при этом не приводя к миллиону возможных параметров (типа "includeUsers=true/false") или неоптимальным ответам (возвращаем все, а клиент разберется).


На мой взгляд, он хорошо подходит и к взаимодействиям сервер-сервер. Например, у нас был проект делать интеграцию со сторонними системами через GraphQL. Для клиент-сервер (например, веб приложение -- сервер) нынче модно думать о более обобщенных протоколах (идеи можно подсмотреть, например, тут: http://tonsky.me/blog/the-web-after-tomorrow/), но это так, пока больше хипстерские замашки, по-моему (хотя я что-то аналогичное сейчас как раз делаю, что забавно, поверх REST API).

Здравствуйте, Gattaka, Вы писали:

G>Здравствуйте, scf, Вы писали:

scf>>Ссылка: http://graphql.org
scf>>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>>Кто-то уже ковырял? Быть может, использовал?
G>Давно присматриваюсь. А насколько хорошо, что клиент содержит в себе бизнес-логику? Т.е. запросы к базе по факту составляются на клиенте. Косяк! То, что они транслируются и что не напрямую — это все спецэффекты.
Это не косяк а гигантский плюс. Кому как не клиенту знать какие данные ему нужны.

Здравствуйте, scf, Вы писали:

scf>Ссылка: http://graphql.org
scf>Вкратце: Новый подход к построению сетевых API, отдающих данные в виде JSON. Интересен простым, в том числе в реализации, и мощным языком запросов.

scf>Кто-то уже ковырял? Быть может, использовал?
А чем принципиально OData не подошёл?

Здравствуйте, Tom, Вы писали:

Tom>А чем принципиально OData не подошёл?

Ну, для начала я о нем раньше и не слышал . А сравнивая с graphql, OData выглядит значительно более сложным и громоздким, при этом решая похожие задачи.

scf>Ну, для начала я о нем раньше и не слышал . А сравнивая с graphql, OData выглядит значительно более сложным и громоздким, при этом решая похожие задачи.
Он работает, реализован Microsoft, интегрирован с EntityFramework, в итоге необходимая задача решается в очень небольшое количество строк/