@akkant

Должен ли graphQL сервер избегать подзапросов в БД?

При использовании традиционного RestAPI один эндпоинт для клиента уже оптимизирован на сервере, вся информация (если она в одной базе) будет взята сервером одним запросом в базу данных (со всеми join-ми или populate-ми).
Если я создаю graphQL сервер, резолвер для каждого связанного(!) под-объекта сам будет обращаться в БД, и тогда один глубокий запрос от клиента может обернуться большим количеством подзапросов от сервера в БД (найти автора -> по автору найти книги -> по книгам найти соавторов -> по соавторам найти количество книг у каждого и тд).
Стоит ли избегать такой ситуации при создании GraphQL сервера и если нужно, то как? (мне на ум приходит только какое-то динамическое создание запросов в БД зависимости от запрашиваемых полей клиентом (опять же со всеми join-ми или populate-ми))
Сюда же можно отнести вопрос о том, стоит ли тащить из БД весь объект, и отдавать клиенту только Несколько запрошенных полей, либо нужно опять динамически создавать запрос в БД только на те поля, что просит клиент (например у автора 300 простых полей, чем бы они не были)
Заранее спасибо за совет.
  • Вопрос задан
  • 115 просмотров
Пригласить эксперта
Ответы на вопрос 2
inoise
@inoise
Solution Architect, AWS Certified, Serverless
Не смотря на то что наворотили реализации GraphQL за последнее время - он НЕ СОЗДАН ДЛЯ ПРЯМОГО ОБРАЩЕНИЯ В БАЗУ ДАННЫХ. Основная цель GraphQL это оркестрация микросервисного ландшафта, не более.

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

Если чуть детальнее то для оптимизации резолверов используется кэширование (настаиваемое), а большое число запросов исключительно масштабированием стоящих за GraphQL микросервисов
Ответ написан
profesor08
@profesor08
Данные из бд придется тащить самому, а то, как ты это сделаешь, будет влиять на производительность. Сам GraphQL лишь обеспечивает единый интерфейс взаимодействия. Если кратко, то на сервере ты получишь некую схему, на основе которой ты можешь получить данные. Это значит, что ты, теоретически, будешь способен построить оптимизированный запрос (объединить все в один запрос и выполнить его).
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
06 авг. 2020, в 13:06
130000 руб./за проект
06 авг. 2020, в 12:55
500 руб./за проект
06 авг. 2020, в 12:18
3000 руб./за проект