33 lines
2.5 KiB
Markdown
33 lines
2.5 KiB
Markdown
|
## Плюсы
|
|||
|
|
Позволяет клиенту запрашивать только те данные, которые ему нужны.
|
|||
|
|
|
|||
|
|
Снимает необходимость несколько раз обращаться за данными.
|
|||
|
|
|
|||
|
|
Уменьшает зависимость клиента от сервера.
|
|||
|
|
|
|||
|
|
Делает разработку более эффективной за счет декларативного описания данных для API.
|
|||
|
|
|
|||
|
|
## Минусы
|
|||
|
|
Уязвимость для атак на исчерпание ресурсов из-за избыточно сложных запросов с большой вложенностью.
|
|||
|
|
|
|||
|
|
В GraphQL сложнее организовать ограничение доступа к данным. Каждый клиент может запросить почти всё, что хочет.
|
|||
|
|
|
|||
|
|
N+1 SQL-запросы (чтобы заполнить все поля-функции данными, может потребоваться новый SQL-запрос на каждое поле). У нас эта проблема решается использованием DataLoader’ов.
|
|||
|
|
|
|||
|
|
Более сложный подход к кэшированию в связи с тем, что в GraphQL нет возможности использовать стандартные для многих механизмы HTTP-кэширования. Для формирования ответа запрос GraphQL должен обязательно дойти до бэкенда.
|
|||
|
|
|
|||
|
|
## Полезные материалы
|
|||
|
|
|
|||
|
|
Статьи:
|
|||
|
|
* [Как упростить жизнь за 312 коротких шагов: проектируем GraphQL API в микросервисной архитектуре](https://habr.com/ru/post/698352/)
|
|||
|
|
* [В этом репозитории очень много полезных советов](https://github.com/nodkz/conf-talks)
|
|||
|
|
* [Статья от нашей компании](https://habr.com/ru/post/662594/)
|
|||
|
|
* [Дополнительная статья от Quarkus](https://quarkus.io/blog/experimental_graphql/)
|
|||
|
|
|
|||
|
|
Доклады:
|
|||
|
|
* [Дизайн GraphQL-схем — строим схемы правильно (версия 2) / Павел Черторогов](https://www.youtube.com/watch?v=tASEYJXdO_c&t=2450s)
|
|||
|
|
|
|||
|
|
## Комментарии
|
|||
|
|
|
|||
|
|
> Тоже встречал такую проблему, сложные запросы вешали сервер по нагрузке. Кучка маленьких рестов оказались много эффективнее.
|