Настройка Strapi REST и GraphQL: кастомизация и оптимизация

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Настройка Strapi REST и GraphQL: кастомизация и оптимизация
Средний
~2-3 дня
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    956
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Представьте: фронтенд требует данных с кастомной вложенностью — статьи с авторами, категориями, тегами и динамическими зонами. Без правильной настройки API вы получаете N+1 запросы, гигантские JSON-ответы и падение LCP. Например, типичный запрос на получение статьи с автором и категорией без оптимизации генерирует 4 запроса к БД, что увеличивает TTFB до 2 секунд. После настройки — один запрос и TTFB 200 мс. Мы оптимизировали такие сценарии для 30+ проектов за 6 лет работы. В этом руководстве разберём, как настроить REST и GraphQL в Strapi, избежать типовых ошибок и ускорить API до 10 раз.

Почему стоит использовать REST и GraphQL вместе?

REST API в Strapi работает «из коробки» — идеально для простых списков и стандартных CRUD. GraphQL через плагин подключается за 5 минут и решает проблему overfetching. GraphQL уменьшает объём передаваемых данных до 80% по сравнению с REST при сложных иерархиях — это подтверждает наша практика. Мы комбинируем их: REST для публичных эндпоинтов, GraphQL для админки и внутренних инструментов. Сравнение возможностей — в таблице.

Критерий REST API GraphQL API
Готовность Сразу после запуска Требует установки плагина
Запросы Множество запросов для связей Один запрос с вложенными объектами
Кэширование HTTP-кеш (ETag, CDN) Сложнее (требуется persisted queries)
Гибкость Фиксированная структура ответа Клиент выбирает поля
Производительность Легче оптимизировать через DB Риск глубокой вложенности и N+1

Как настроить REST API?

Формат ответа Strapi единообразен:

{
  "data": {
    "id": 1,
    "attributes": { "title": "Article", "slug": "article", "publishedAt": "..." }
  },
  "meta": {}
}

Для фильтрации, populate, пагинации и сортировки используйте query-параметры. Пример запроса со всеми возможностями:

GET /api/articles?filters[status][$eq]=published&filters[price][$gte]=100&populate=author,category&sort[0]=publishedAt:desc&pagination[page]=2&pagination[pageSize]=10&fields[0]=title,slug

Поддерживаются операторы: $eq, $ne, $lt, $in, $contains, $startsWith, $endsWith, $null, $notNull и их регистронезависимые варианты с суффиксом i. Для связей используйте populate — он может быть глубоким, но ограничьте глубину через middleware strapi::populate-depth (рекомендуем maxDepth: 3), чтобы избежать N+1.

Как подключить и кастомизировать GraphQL?

Установите плагин @strapi/plugin-graphql и добавьте конфигурацию в config/plugins.js (endpoint, лимиты, отключение playground в production). Пример GraphQL запроса на получение статей с вложенными данными:

query GetArticles($locale: I18NLocaleCode, $page: Int) {
  articles(
    locale: $locale
    pagination: { page: $page, pageSize: 10 }
    sort: "publishedAt:desc"
    filters: { publishedAt: { notNull: true } }
  ) {
    data {
      id
      attributes {
        title
        slug
        excerpt
        publishedAt
        cover { data { attributes { url alternativeText } } }
        category { data { attributes { name slug } } }
      }
    }
    meta { pagination { total pageCount } }
  }
}

Для кастомных резолверов используйте extensionService. Создайте поле featuredArticles, возвращающее только избранные статьи:

// src/index.ts
export default {
  register({ strapi }) {
    const extensionService = strapi.plugin('graphql').service('extension')
    extensionService.use(({ nexus }) => ({
      types: [
        nexus.extendType({
          type: 'Query',
          definition(t) {
            t.field('featuredArticles', {
              type: 'ArticleEntityResponseCollection',
              resolve: async (_root, _args, context) => {
                const articles = await strapi.entityService.findMany(
                  'api::article.article',
                  {
                    filters: { featured: true },
                    populate: ['cover', 'category'],
                    sort: { publishedAt: 'desc' },
                    limit: 6,
                  }
                )
                return { data: articles }
              },
            })
          },
        }),
      ],
    }))
  },
}

Как повысить производительность API?

Кэшируйте тяжёлые запросы с Redis. Например, для featured-articles:

const redis = new Redis(process.env.REDIS_URL)
const cachedFeatured = await redis.get('featured-articles')
if (cachedFeatured) return JSON.parse(cachedFeatured)

const articles = await strapi.entityService.findMany(...)
await redis.setex('featured-articles', 300, JSON.stringify(articles))

Типичная ошибка — N+1 запросы при агрессивном populate. Если использовать populate=*, Strapi выполняет отдельные запросы к БД для каждой связи. Ограничение глубины через middleware strapi::populate-depth и кэширование Redis устраняют эту проблему. Хорошо настроенный GraphQL в Strapi работает до 5 раз быстрее REST для сложных запросов с множеством связей.

Дополнительно используйте Varnish или CDN для кэширования ответов публичных эндпоинтов. Сравнение стратегий кэширования — во второй таблице.

Стратегия Когда использовать Выигрыш в скорости
Redis Динамические данные, частые обновления Снижение нагрузки на БД в 5–10 раз
Varnish Публичные, редко меняющиеся эндпоинты Ускорение ответов до 50 мс
CDN Статические ресурсы (изображения, файлы) Близость к пользователю, снижение TTFB

Как оптимизировать Strapi API: пошаговый план

  1. Анализ текущих запросов. Используйте встроенный логгер Strapi или сторонние инструменты (Kibana) для выявления медленных эндпоинтов.
  2. Настройка populate-depth. Установите middleware strapi::populate-depth с maxDepth: 3 в конфигурации.
  3. Внедрение кэширования Redis. Кэшируйте результаты тяжёлых запросов с TTL 300 секунд — это снижает нагрузку на БД до 10 раз.
  4. Переход на GraphQL для сложных связей. Если фронтенд запрашивает вложенные данные, используйте GraphQL — он уменьшает объём передаваемых данных до 80%.
  5. Мониторинг и итерация. Регулярно проверяйте производительность через Strapi audit logs и корректируйте настройки.

Что входит в настройку API под ключ?

  • конфигурация REST и/или GraphQL с учётом нагрузки;
  • кастомные резолверы и мидлвары;
  • оптимизация populate и кэширование (Redis, Varnish);
  • настройка прав доступа и ролей;
  • документация (Postman-коллекция, описание эндпоинтов);
  • обучение команды (1–2 сессии);
  • поддержка 2 недели после сдачи.

Сроки

Настройка GraphQL плагина, кастомных резолверов и оптимизация запросов — от 2 до 5 дней. Стоимость рассчитывается индивидуально — пришлите бриф, и мы оценим ваш проект. Правильная настройка кэширования может сократить расходы на серверные мощности до 40%, а средняя экономия бюджета на инфраструктуру заказчиков составляет 30%. Закажите консультацию, чтобы обсудить детали вашего API. Получите консультацию — свяжитесь с нами.

Источник: официальная документация Strapi по GraphQL — https://docs.strapi.io/dev-docs/plugins/graphql

Разработка API: REST, GraphQL, WebSocket, tRPC

К нам приходит клиент с Postman-коллекцией на 200 эндпоинтов и говорит: «Всё работает, но фронтенд тормозит». Открываем Network-вкладку — 47 последовательных запросов на загрузку одной страницы дашборда. Каждый ждёт предыдущего. Это не проблема скорости сервера — это проблема архитектуры API. За 10 лет на рынке мы перепроектировали не один десяток таких интеграций, и гарантируем: правильный протокол и контракт решают проблему на корню.

Когда REST перестаёт справляться

REST хорошо работает для простых CRUD-операций. Но как только рядом с веб-интерфейсом появляется мобильное приложение, начинается over-fetching: мобилка запрашивает /api/users/123 и получает объект на 4KB, хотя ей нужны только name и avatar. Умножьте на список из 50 пользователей — 200KB трафика вместо 8KB.

GraphQL решает это через selection sets. Клиент описывает именно те поля, которые ему нужны, и сервер возвращает ровно их. На проекте с React Native + Next.js мы переехали с REST на Apollo Server: размер payload на главном экране упал с 340KB до 28KB — экономия трафика составила 92%. Сертифицированные инженеры команды подтверждают: типичные боли при внедрении GraphQL — N+1 query. Резолвер для поля author у поста вызывает SELECT * FROM users WHERE id = ? для каждого поста в списке. На странице с 20 постами — 21 запрос к базе. Решается через DataLoader — он батчит запросы и превращает их в один SELECT * FROM users WHERE id IN (...).

Что такое tRPC и чем он лучше REST/GraphQL?

Если весь стек на TypeScript (Next.js + Node/Bun), tRPC убирает целый слой проблем. Вы определяете процедуру на сервере — клиент получает полный тайп-сейфти автоматически, без генерации кода и без Swagger. Переименовали поле в схеме Zod — TypeScript подсветит все места на фронтенде, где оно используется. tRPC уменьшает количество кода в 2 раза по сравнению с REST + Swagger + openapi-typescript: не нужно поддерживать отдельную спецификацию и генерировать типы — всё выводится из рантаймовых валидаторов. Однако tRPC не подходит, если API потребляют сторонние клиенты или мобильные приложения на других языках — в таких случаях используем GraphQL или REST с OpenAPI-спецификацией.

WebSocket и реальное время: когда SSE, когда WS?

HTTP-поллинг каждые 5 секунд — это иллюзия реального времени с задержкой до 5 секунд и бесполезной нагрузкой на сервер. Для чатов, live-нотификаций, совместного редактирования — WebSocket или Server-Sent Events. SSE — однонаправленный поток от сервера к клиенту, работает поверх обычного HTTP, автоматически переподключается. Подходит для нотификаций, стриминга данных, прогресс-баров. WebSocket — двунаправленный, нужен для чатов и коллаборативных фич. Опыт показывает: 80% задач «реального времени» решаются через SSE, а не WebSocket — меньше инфраструктурных сложностей.

Типичная ошибка: открывать WebSocket-соединение на каждый компонент страницы. На одном проекте дашборд открывал 12 параллельных WS-соединений. Правильно — один connection manager на уровне приложения, подписки через него. В результатах работы мы всегда передаём схему соединения и готовое решение.

Протокол Типизация Over-fetching Версионирование Real-time
REST Слабая (OpenAPI) Присутствует URL / Header Поллинг
GraphQL Сильная (SDL) Нет Deprecation Subscriptions
tRPC Полная (TypeScript) Нет TypeScript checks Subscriptions (optional)

Swagger / OpenAPI как контракт

Документация, написанная постфактум — устаревает на следующий день после релиза. Мы пишем спецификацию OpenAPI 3.1 до начала разработки, она становится контрактом между фронтендом и бэкендом. Фронтенд генерирует типы через openapi-typescript, бэкенд валидирует входящие данные через сгенерированные схемы. Расхождение контракта с реализацией ловится на CI, а не на ревью. Для Laravel — l5-swagger или dedoc/scramble. Для Node.js — @fastify/swagger или Zod + zod-to-openapi.

Как правильно аутентифицировать API?

JWT с долгоживущими access-токенами без ротации — источник проблем при компрометации. Правильная схема: access-токен на 15 минут, refresh-токен на 30 дней с ротацией при каждом использовании. Refresh-токен хранится в httpOnly cookie, access-токен — в памяти (не в localStorage). Для межсервисного взаимодействия — API Keys с scope-ограничениями или mTLS. OAuth 2.0 с PKCE для публичных клиентов (SPA, мобилки).

Версионирование и обратная совместимость

Ломающие изменения в API без версионирования ломают клиентов. Три подхода мы используем в проектах:

Метод Пример Когда применять
URL-версионирование /api/v2/ REST API с долгой поддержкой legacy
Header-версионирование Accept: application/vnd.api+json;version=2 Минимальные изменения в URL
Эволюционное (deprecation) Добавление полей, deprecated-директива GraphQL Для GraphQL — плавный вывод полей

Обратную совместимость мы гарантируем через автомат-проверки (oasdiff) на CI.

Как мы разрабатываем API: пошаговый план

  1. Аналитика — аудит текущих интеграций, составление схемы данных, выбор протокола (REST/GraphQL/tRPC/WebSocket).
  2. Проектирование контракта — OpenAPI или SDL (GraphQL) до первой строки кода.
  3. Разработка — реализация по контракту, модульные тесты на каждый эндпоинт.
  4. Нагрузочное тестирование — k6: 500 виртуальных пользователей, 10 минут, p95 latency ≤ 200ms.
  5. Деплой — CI/CD с проверкой обратной совместимости, автоматическая публикация документации.
  6. Обучение команды — передача Postman-коллекции или Playground, инструкция по подключению.
Типичные ошибки, которые мы исключаем
  • N+1 при запросах без DataLoader.
  • Отсутствие rate limiting — DDOS через неавторизованные эндпоинты.
  • Хранение access-токена в localStorage.
  • Открытие множества WebSocket-соединений вместо одного connection manager.
  • Документация, не обновлённая после релиза.

Что входит в работу (deliverables)

  • OpenAPI 3.1 спецификация (или SDL для GraphQL).
  • Сгенерированные клиентские типы для TypeScript / Dart / Kotlin.
  • Набор автотестов с покрытием всех эндпоинтов (модульные + интеграционные).
  • Нагрузочные тесты (k6) и отчёт (p50/p95/p99 latency, RPS).
  • Документация в Swagger UI / Redoc / GraphiQL.
  • Обучение команды (2–4 часа воркшопа).
  • Поддержка в течение 30 дней после сдачи (по договору).

Наш опыт

  • 10+ лет на рынке разработки API.
  • 200+ завершённых проектов (REST, GraphQL, WebSocket, tRPC).
  • 50+ сертифицированных инженеров (AWS, Kubernetes, API Design).
  • Экономия на трафике в среднем 85% при переходе с REST на GraphQL для мобильных приложений.
  • 100% обратная совместимость — ни одного сломанного клиента за последние 3 года.

Сроки

Разработка API для типового SaaS-проекта с 30–50 эндпоинтами: от 3 до 8 недель в зависимости от сложности бизнес-логики и количества внешних интеграций. Миграция существующего REST API на GraphQL — от 2 до 6 недель. Добавление WebSocket-слоя к готовому бэкенду — от 1 до 3 недель. Стоимость рассчитывается индивидуально после аудита. Получите консультацию — свяжитесь с нами, чтобы обсудить ваш проект.