Должен ли graphQL сервер избегать подзапросов в БД?
При использовании традиционного RestAPI один эндпоинт для клиента уже оптимизирован на сервере, вся информация (если она в одной базе) будет взята сервером одним запросом в базу данных (со всеми join-ми или populate-ми).
Если я создаю graphQL сервер, резолвер для каждого связанного(!) под-объекта сам будет обращаться в БД, и тогда один глубокий запрос от клиента может обернуться большим количеством подзапросов от сервера в БД (найти автора -> по автору найти книги -> по книгам найти соавторов -> по соавторам найти количество книг у каждого и тд).
Стоит ли избегать такой ситуации при создании GraphQL сервера и если нужно, то как? (мне на ум приходит только какое-то динамическое создание запросов в БД зависимости от запрашиваемых полей клиентом (опять же со всеми join-ми или populate-ми))
Сюда же можно отнести вопрос о том, стоит ли тащить из БД весь объект, и отдавать клиенту только Несколько запрошенных полей, либо нужно опять динамически создавать запрос в БД только на те поля, что просит клиент (например у автора 300 простых полей, чем бы они не были)
Заранее спасибо за совет.
Не смотря на то что наворотили реализации GraphQL за последнее время - он НЕ СОЗДАН ДЛЯ ПРЯМОГО ОБРАЩЕНИЯ В БАЗУ ДАННЫХ. Основная цель GraphQL это оркестрация микросервисного ландшафта, не более.
Все остальные нюансы вроде "большого" числа запросов и полей просто излишни. GraphQL это не про оптимизацию, а про создание единого интерфейса для стоящих за ним микросервисов. Эдакий API Gateway с параллелизмом внутри.
Если чуть детальнее то для оптимизации резолверов используется кэширование (настаиваемое), а большое число запросов исключительно масштабированием стоящих за GraphQL микросервисов
Стоит еще добавить что GraphQL имеет исключительно базовый уровень валидации схемы именно по тому что при мутации валидация должна происходить в микросервисе
Спасибо Вам за ответ, но я попробую уточнить вопрос:
GraphQL предоставляет клиенту гибкую возможность брать любые поля любых объектов в одном запросе (при условии нормальной "волосатой" схемы)
не вдаваясь в подробности, в проблему n+1 и тд., на простом высоком уровне:
1. должен ли сервер так же, динамически, обращаться в БД только за теми полями, что попросил клиент (вытащить из базы Только нужные поля либо вытащить Все 300 полей одного объекта и отдать только нужные клиенту)?
2. должен ли сервер динамически создавать подзапросы (взять автора + populate книги) либо допустимо обратиться с сервера в БД 2 и более (50) раз?
1. должен ли сервер так же, динамически, обращаться в БД только за теми полями, что попросил клиент (вытащить 300 полей одного объекта и отдать только нужные клиенту либо вытащить из базы только нужные)?
Вытащить только нужные. Время процессинга данных и память не резиновые в любом случае
2. должен ли сервер динамически создавать подзапросы (взять автора + populate книги) либо допустимо обратиться в БД 2 и более раз?
akkant, но я еще раз повторюсь - если у вас резолвер берет данные напрямую из базы данных то у вас все очень плохо и далеко не уедет. Может быть на короткой дистанции это может сработать, как процесс первичной интеграции
Данные из бд придется тащить самому, а то, как ты это сделаешь, будет влиять на производительность. Сам GraphQL лишь обеспечивает единый интерфейс взаимодействия. Если кратко, то на сервере ты получишь некую схему, на основе которой ты можешь получить данные. Это значит, что ты, теоретически, будешь способен построить оптимизированный запрос (объединить все в один запрос и выполнить его).
Простой
Средний
Сложный
