Тоже сейчас задаюсь этим вопросом, нужно сделать круд на фронте для хасуры. Может кто-то знает хорошие готовые решения?

https://bit.ly/graphql-dx (слайды 70-81).

Самый примитивный способ — ограничить глубину запроса (это называется Query depth limiting).

Чуть продвинутее — вычислить сложность запроса на основе размера ответа (это называется Query cost/complexity analysis): каждому полю задается вес, веса полей на одном уровне вложенности складываются, веса вложенных полей перемножаются, задается пороговое значение, если финальный вес запроса меньше порогового — выполняем запрос, если больше — возвращаем ошибку.

Веса можно взять из Apollo Studio. Если подключить отправку телеметрии своего GraphQL API в Apollo Studio, то через какое-то время там накопится статистика в миллисекундах. Если, например, одно поле резолвится в среднем за 13 мс и мы даем ему вес 1, то поле, которое резолвится в среднем за 39 мс, будет иметь вес 3.

Но и это не панацея, злоумышленник может методом подбора вычислить пороговое значение на сервере и сконструировать такой запрос, сложность которого лишь немного меньше порогового и делать такой запрос к серверу часто (и сервер будет обязан выполнять запрос). Поэтому можно ограничить частоту запросов (количество запросов в течение фиксированного временного окна) (это называется Fixed-size time window (rate) limiting).

Причем одно другое другое не исключает, а дополняет. Нужно использовать и Query cost/complexity analysis, и Fixed-size time window (rate) limiting вместе.

Для Query cost/complexity analysis и Fixed-size time window (rate) limiting есть пакеты в npm.

Веса полей и ограничения частоты запроса полей указываются с помощью специальных директив в SDL.

Но сложность запроса зависит не только от полей, но и от аргументов. Например, если сложность получения одного поста равна 1, то сложность получения массива из 50 постов — 50.

Поэтому помимо весов полей есть еще множители, которые тоже указываются в директивах (см. слайд 75).

Для более сложных аргументов (например, произвольного where) определить множители нетривиально: там нет такого простого алгоритма как для запрашиваемых полей, где веса полей на одном уровне вложенности складываются, а веса вложенных полей перемножаются или другого подобного простого алгоритма (все зависит от источника, откуда мы получаем данные: из стороннего API или базы данных, типа базы данных, вычислен ли у нас ответ на такой запрос или нет и т.д.).

Для Fixed-size time window (rate) limiting (не в порядке приоритета/функционала):

https://www.npmjs.com/package/graphql-rate-limit

https://www.npmjs.com/package/graphql-rate-limit-directive

Для Query cost/complexity analysis (не в порядке приоритета/функционала):

https://www.npmjs.com/package/graphql-validation-complexity

https://www.npmjs.com/package/graphql-cost-analysis

https://www.npmjs.com/package/graphql-query-complexity

Еще, если у вас не публичное API для всех, которое подразумевает произвольные запросы, то в качестве защиты можно использовать Query whitelisting и Persisted queries. Это когда собирается список всех запросов в вашем приложении и добавляется в белый список на сервере (для каждого запроса вычисляется хэш и дальше вместо самого запроса на сервер отправляется хэш). Любые другие запросы, отличные от тех, что в белом списке будут возвращать ошибку. Обычно еще и интроспекцию отключают, чтобы нельзя было посмотреть схему.

@nodkz По-моему, достаточно подробный ответ на довольно распространенный вопрос получился. Было бы неплохо сохранить его куда-нибудь для будущих поколений. ;)

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

Открывай PR а репку, чтоб заерепить твое авторство

++++++++++++++++

Здесь потеряется через пару часов((

Так это, запинить же
Сейчас же можно множественные пины

Столкнулся с проблемой. Есть объект user {id, name, thumbs {small}}. И в thumbs каждый раз приходит разные значение thumbs {small} из-за того что подписываю url картинки. Допустим я залогинился, и беру account { currentUser {id, name, thumbs {small}}}. И показываю картинку в правом верхнем углу. Проблема возникает когда я подгружаю какую-либо таблицу и в ней допустим создатель стоки - это я, т.е. createdBy: {id, name, thumbs {small}}. У меня смотрим внутренний кэш, что тааакс, у нас есть уже такой пользователь, но thumbs{small} у него другой - нужно обновить его - и обновляет, и из-за этого обновляет account {currentUser} и соответственно ре-рендерит страницу бесконечно.

как отключить кэширование для этих полей?

пробовал в typePolicies далать Image : {keyFields: false} но не помогает

В 20:00 MSK начинается Apollo Day. Можно будет задать вопросы команде. )

https://twitter.com/apollographql/status/1326171847340273665

Команда Apollo — молодцы. В своём Apollo Studio Explorer реализовали многие многие мои идеи из треда https://github.com/OneGraph/graphiql-explorer/issues/10. 😊