Сообщение Re: Кто что думает про GraphQL? от 22.02.2017 19:40
Изменено 22.02.2017 19:41 Иван Дубров
Re: Кто что думает про GraphQL?
Здравствуйте, 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).
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).
Re: Кто что думает про GraphQL?
Здравствуйте, 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).
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).