Архитектура и GraphQL

В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы. Теперь перейдём к архитектуре — фундаменту, определяющему, как GraphQL API будет работать в реальных условиях.
Архитектура GraphQL отличается от традиционных REST API. Вместо множества эндпоинтов используется единая точка входа. Это создаёт уникальные вызовы: как организовать код, обеспечить производительность, масштабировать систему и интегрировать различные источники данных.

Выбранная архитектура определяет:
■ Насколько легко будет развивать API;
■ Как система справится с нагрузкой;
■ Сложность поддержки и отладки;
■ Возможность командной работы.

В этой статье мы рассмотрим архитектурные паттерны GraphQL — от монолитных решений до федеративных систем. А также изучим основные принципы организации серверной части.

Мы не будем углубляться в типичные проблемы продакшена, такие как N+1 запросы, стратегии кеширования или защита от сложных запросов — эти важные темы будут рассмотрены в следующих статьях цикла.

Разберём, что такое GraphQL-сервер и как он устроен.

По сути GraphQL — это просто спецификация. Чтобы превратить её в работающий API, нужно реализовать серверную часть, которая сможет принимать запросы, проверять их и возвращать клиенту результат.

Сначала определимся с тем, что такое GraphQL-сервер, как он устроен и какие функции выполняет, а после рассмотрим, как он встраивается в жизненный цикл запроса.

GraphQL-сервер — это программа, которая служит средой выполнения для GraphQL-запросов.

То есть, GraphQL-сервер:

1. Принимает GraphQL-запросы от клиентов.
2. Проверяет их корректность.
3. Выполняет запросы (получает данные).
4. Возвращает ответ в нужном формате.

У каждого GraphQL-сервера есть несколько ключевых компонентов: схема, резолверы и контекст. Ниже рассмотрим каждый из них.

Схема описывает типы данных и операции (запросы, мутации и подписки), доступные клиентам. Это своего рода договор между сервером и клиентом: всё, что не описано в схеме, запросить нельзя. Мы подробно рассматривали схему во второй статье цикла.

Есть два подхода к работе со схемой:

■ Schema-first предполагает, что сначала пишется схема в SDL (специальном декларативном языке), а затем для неё реализуются резолверы.
Описание схемы перед разработкой облегчает совместную работу над API и создаёт единый источник правды. Такой подход требует больше ручной работы по синхронизации схемы и кода.

■ Code-first — противоположный подход: схема генерируется автоматически на основе кода. Это может быть быстрее в разработке и проще в поддержке. Однако на больших и сложных проектах такой подход может вносить путаницу.

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

■ Официальная документация и черновик спецификации
■ Руководство по GraphQL
■ Книга «GraphQL» Алекс Бэнкс, Ева Порселло
■ Вебинар «Особенности использования GraphQL»
■ Спецификация Relay
■ Инструменты для работы с GraphQL:
      ○ GraphiQL — IDE для интерактивного тестирования запросов
      ○ Apollo Studio — облачный инструмент для анализа и отладки схем
      ○ Postman и Insomnia — поддерживают GraphQL-запросы из коробки