Кто такой этот ваш Граф Ку Эль GraphQL — язык запросов для API, позволяющий клиентам точно указать набор данных, которые ему нужны.
А чем же не угодил REST?
Основная проблема заключается в том, что RESTful API предоставляет единый интерфейс для всех клиентов сервера. Но это за собой влечет overfetching и underfetching.
Например, у нас в процессе есть необходимость получения данных клиента. Но нам требуется получение только уникального идентификатора на основе договора. RESTful API в данном случае может быть устроена так, что вернется большой набор данных, включающий ФИО, информацию по всем договорам, счетам, ИНН, контактные данные и тд. Это называется overfetching. Соответственно, обработка лишних данных ведет к потере производительности, повышению нагрузки сети, а также замедлению загрузки страницы приложения.
А underfetching обратная проблема, проблема недостаточности данных в ответе. Соответственно, для получения всех данных приходится слать несколько запросов для получения всех ресурсов. Это влечет за собой примерно те же проблемы помимо усложнения логики.
А чаще всего происходит сразу обе проблемы, клиент делает несколько запросов, при этом в каждом запросе ему нужны далеко не все данные.
Так вот GraphQL предназначен для решения этих проблем. Если вкратце, то сервер предоставляет возможные для получения данные, а клиент сам описывает что ему нужно получить.
Таким образом, клиент одним запросом получает список всех нужных параметров, не отправляя запросы на несколько разных эндпоинтов, а также не получая лишние для него данные.
· 07.06
Не понял почему автор считает, что мы не можем получить только то что нам нужно. Для чего fetch тогда? Или entityGraph?
ответить
коммент удалён
· 08.06
Ааа) туплю, братан! Я с графкуэль не сталкивался. По обыкновению написал бы метод с кастомным запросом и всё)
ответить
ответ удалён
· 08.06
Ну само собой это не рест, это графкуэль)
ответить
ответ удалён
· 08.06
Но ведь получается, что это уже не REST. REST на то и REST, чтоб получать ресурсоподобные данные. С тем же успехом, я думаю, можно использовать кастомные запросы. Но, вероятно, GraphQL, удобнее.
ответить
ответ удалён
· 08.06
Говоря, что ты получаешь только то, что нужно, это не правда, ты получаешь все, что предусмотрено эндпоинтом и логикой на бэке, а далее уже обрезаешь не нужные тебе данные при парсинге ответа и дальнейшем маппинге.
ответить
ответ удалён
· 08.06
Рест про универсальность, отсюда эндпоинт, на который стучатся разные потребители, но получают одинаковый набор данных. Условно по идентификатору пользователя получаем все его данные: ФИО, ИНН, контактное инфо, платежную инфо. Но не всем нужны именно все эти данные. Это первая проблема, вторая проблема заключается в том, что каждый эндпоинт предоставляет взаимодействие с одним ресурсом. Если быть точным это не проблемы, а данность, которая вытекает из стиля реста.
И вот основная фишка графкуэль - решение «проблем» реста для оптимизации высоконагруженных взаимодействий.
ответить
ответ удалён
· 08.06
Я просто не совсем понял о чем проблема. Сделал разные предположения.
ответить
ответ удалён
· 08.06
Потому что при использовании песта клиент не решает и не определяет состав полей. Сколько в эндпоинте заложено данных, столько и вернется. EntityGraph вообще не понял к чему
ответить
ответ удалён