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 с. Гарантуємо чисту реалізацію без просадки з безпеки. Впроваджуємо Persisted Queries під ключ за 2-5 днів.
Як працюють Automatic Persisted Queries (APQ)?
APQ — двофазний протокол. Клієнт спочатку надсилає POST-запит лише з хешем. Якщо кеш сервера не містить запит — повертається 404. Тоді клієнт повторює запит з повним тілом. Сервер зберігає пару хеш→запит і повертає дані. Всі наступні виклики — лише хеш, причому можна перейти на GET-запити, які кешуються на CDN. Це прискорює відповідь у 3-5 разів порівняно з без кешування.
Клієнт Сервер CDN/Cache │ │ │ │ POST {hash} │ │ │───────────────>│ │ │ 404 Not Found │ │ │<───────────────│ │ │ │ │ │ POST {hash + query body} │ │───────────────>│ │ │ {data} [зберегти hash→query] │ │<───────────────│ │ │ │ │ │ GET ?hash=... │ │ │──────────────────────────────> │ │ {data} з кеша │ │<────────────────────────────── │ Порівняння підходів: APQ vs Registered PQ vs відсутність PQ
| Критерій | Без Persisted Queries | APQ | Registered PQ |
|---|---|---|---|
| Розмір запиту | Повний (до 15 КБ) | Хеш (44 байти) + зрідка повний | Тільки хеш |
| CDN-кешування | Тільки якщо ідемпотентні | GET-запити кешуються | GET-запити кешуються |
| Безпека | Будь-який запит | Будь-який запит після реєстрації | Тільки зареєстровані |
| Складність впровадження | — | Низька (1-2 дні) | Середня (3-5 днів) |
Оптимізація GraphQL запитів за допомогою Persisted Queries підвищує продуктивність API та покращує Core Web Vitals (LCP, FID). GraphQL кешування на CDN зменшує навантаження на сервер.
Замовте впровадження Persisted Queries — ми покажемо метрики до та після на тестовому стенді. Оцінимо ваш проект безкоштовно.
Чому варто використовувати Registered Persisted Queries?
Registered Persisted Queries (RPQ) — це APQ + білий список. У продакшен дозволені лише запити, чиї хеші є в маніфесті. Це виключає атаки через інтроспекцію схеми або довільні мутації, забезпечуючи високий рівень GraphQL безпеки. Маніфест генерується з клієнтського коду на етапі збірки.
# Генерація маніфесту з клієнтських операцій 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, яке підставляє тіло запиту з маніфесту та відхиляє невідомі хеші.
Реальний кейс: RPQ для фінтех-додатку
У проекті з високими вимогами до безпеки (обробка платежів) ми впровадили RPQ. Згенерували маніфест зі 120 операцій, налаштували строгий контроль. Результат — нульова кількість інцидентів за півроку, TTFB скоротився на 40% завдяки GET-кешуванню на Cloudflare. Економія на інфраструктурних ресурсах склала 30%.Типові проблеми та їх рішення
| Проблема | Рішення |
|---|---|
| Застарівання кеша при зміні схеми | Використовуйте Redis з TTL 24 години та інвалідацію за версією схеми |
| Відсутність підтримки APQ в бібліотеці | Реалізуйте middleware: на сервері перевіряйте вхідний JSON на наявність extensions.persistedQuery |
| Повільна генерація маніфесту при CI | Інкрементальна збірка: зберігайте попередній маніфест і оновлюйте лише змінені файли |
Як ми впроваджуємо Persisted Queries: покроково
- Аудит поточного GraphQL API: аналіз розміру запитів, частоти дублювання, використовуваного кешування.
- Проектування: вибір підходу (APQ або RPQ), визначення TTL, налаштування Redis для розподіленого кеша.
- Реалізація на клієнті: впровадження
createPersistedQueryLinkв Apollo Client або аналогічного для Relay/Urql. - Реалізація на сервері: підключення APQ (в Apollo Server вбудоване), налаштування кеша, додавання middleware для RPQ при необхідності.
- Тестування: перевірка коректності кешування, моніторинг хіт-ратів.
- Деплой та 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 днів. Вартість розраховується індивідуально в залежності від складності схеми та кількості клієнтів. Економія на інфраструктурі може сягати 30%.
Прискорте свій GraphQL API — пишіть нам для оцінки вашого проекту. Покажемо метрики до та після на тестовому стенді. Оцінимо проект безкоштовно.