2.5 KiB
Плюсы
Позволяет клиенту запрашивать только те данные, которые ему нужны.
Снимает необходимость несколько раз обращаться за данными.
Уменьшает зависимость клиента от сервера.
Делает разработку более эффективной за счет декларативного описания данных для API.
Минусы
Уязвимость для атак на исчерпание ресурсов из-за избыточно сложных запросов с большой вложенностью.
В GraphQL сложнее организовать ограничение доступа к данным. Каждый клиент может запросить почти всё, что хочет.
N+1 SQL-запросы (чтобы заполнить все поля-функции данными, может потребоваться новый SQL-запрос на каждое поле). У нас эта проблема решается использованием DataLoader’ов.
Более сложный подход к кэшированию в связи с тем, что в GraphQL нет возможности использовать стандартные для многих механизмы HTTP-кэширования. Для формирования ответа запрос GraphQL должен обязательно дойти до бэкенда.
Полезные материалы
Статьи:
- Как упростить жизнь за 312 коротких шагов: проектируем GraphQL API в микросервисной архитектуре
- В этом репозитории очень много полезных советов
- Статья от нашей компании
- Дополнительная статья от Quarkus
Доклады:
Комментарии
Тоже встречал такую проблему, сложные запросы вешали сервер по нагрузке. Кучка маленьких рестов оказались много эффективнее.