Внедрение GraphQL Persisted Queries: ускорение и безопасность API

GraphQL Persisted Queries: ускоряем API в разы

Мы часто сталкиваемся с ситуацией: клиентское приложение отправляет огромные GraphQL-запросы (например, query { user { posts { comments { author { ... } } } } }), которые «весят» 10–15 КБ. На мобильном интернете это даёт TTFB в 3–5 секунд. Persisted Queries решают проблему кардинально: вместо полного тела запроса клиент отправляет только SHA256-хеш (44 байта). Сервер (или CDN) возвращает кешированный ответ. Это снижает трафик на 60% и позволяет кешировать запросы на уровне HTTP. По оценкам Apollo, APQ уменьшают размер запроса в 20 раз для повторных вызовов.

Наш опыт: за последние годы мы внедрили эту технику в 30+ проектах. В одном из кейсов (интернет-магазин с миллионом товаров) APQ сократили размер запросов с 8 КБ до 400 байт, а LCP упало с 3.2 с до 1.1 с. Гарантируем чистую реализацию без просадки по безопасности.

Как работает Automatic Persisted Queries (APQ)?

APQ — двухфазный протокол. Клиент сначала отправляет POST-запрос только с хешем. Если кеш сервера не содержит запрос — возвращается 404. Тогда клиент повторяет запрос уже с полным телом. Сервер сохраняет пару хеш→запрос и возвращает данные. Все последующие вызовы — только хеш, причём можно перейти на GET-запросы, которые кешируются на CDN.

Клиент Сервер CDN/Cache │ │ │ │ POST {hash} │ │ │───────────────>│ │ │ 404 Not Found │ │ │<───────────────│ │ │ │ │ │ POST {hash + query body} │ │───────────────>│ │ │ {data} [сохранить hash→query] │ │<───────────────│ │ │ │ │ │ GET ?hash=... │ │ │──────────────────────────────> │ │ {data} из кеша │ │<────────────────────────────── │ 

Сравнение подходов: APQ vs Registered PQ vs отсутствие PQ

Оптимизация GraphQL запросов с помощью Persisted Queries повышает производительность API и улучшает Core Web Vitals.

Закажите внедрение Persisted Queries — мы покажем метрики до и после на тестовом стенде.

Почему стоит использовать Registered Persisted Queries?

Registered Persisted Queries (RPQ) — это APQ + белый список. В продакшен разрешены только запросы, чьи хеши есть в манифесте. Это исключает атаки через __schema или произвольные мутации. Манифест генерируется из клиентского кода на этапе сборки.

# Генерация манифеста из клиентских операций npx generate-persisted-query-manifest \ --documents "src/**/*.graphql" \ --output persisted-query-manifest.json 

// persisted-query-manifest.json (фрагмент) { "format": "apollo-persisted-query-manifest", "version": 1, "operations": [ { "id": "dc67510fb4289672bea757e862d6b00e...", "name": "GetPosts", "type": "query", "body": "query GetPosts($limit: Int) { posts(first: $limit) { ... } }" } ] } 

На сервере достаточно middleware, которое подставляет тело запроса из манифеста и отклоняет неизвестные хеши.

Типичные проблемы и их решения

Как мы внедряем Persisted Queries: пошагово

1. Аудит текущего GraphQL API: анализ размера запросов, частоты дублирования, уже используемого кеширования.
2. Проектирование: выбор подхода (APQ или RPQ), определение TTL, настройка Redis для распределённого кеша.
3. Реализация на клиенте: внедрение createPersistedQueryLink в Apollo Client или аналогичного для Relay/Urql.
4. Реализация на сервере: подключение APQ (в Apollo Server встроено), настройка кеша, добавление middleware для RPQ при необходимости.
5. Тестирование: проверка корректности кеширования, мониторинг хит-ратов.
6. Деплой и CDN: настройка Nginx для кеширования GET-запросов, включение Cloudflare или Vercel Edge.

Что входит в работу

• Документирование схемы и манифеста.
• Настройка мониторинга попаданий в кеш (Prometheus/Grafana).
• Обучение команды поддержке и обновлению манифеста.
• Пост-релизная поддержка в течение 2 недель.
• Передача доступа к репозиторию и документации.

Мы применяем проверенные конфиги. Пример настройки Nginx:

proxy_cache_path /var/cache/nginx/graphql levels=1:2 keys_zone=graphql:10m max_size=100m inactive=1h use_temp_path=off; location /graphql { if ($request_method = GET) { proxy_cache graphql; proxy_cache_key "$uri$is_args$args"; proxy_cache_valid 200 5m; proxy_cache_use_stale error timeout updating; add_header X-Cache-Status $upstream_cache_status; } proxy_pass http://api_backend; } 

Сроки и стоимость

Базовая настройка APQ с Redis и CDN — от 1 до 2 рабочих дней. Полный цикл с Registered Persisted Queries, манифестом и мониторингом — от 3 до 5 дней. Стоимость рассчитывается индивидуально в зависимости от сложности схемы и количества клиентов.

Ускорьте свой GraphQL API — свяжитесь с нами для оценки вашего проекта. Покажем метрики до и после на тестовом стенде.