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

Вариант 2 не подходит для статических запросов.

Как я уже говорил в комментарии, подумайте о том, что действительно нужно вашему приложению. Если вы хотите искать динамическое количество полей по идентификатору, вариант 2 не будет полезен, если вы хотите использовать статические запросы. Вам нужно будет объединять строки для создания динамических запросов примерно так:

const query = `{ ${ids.map(id => `product${id}: product { ...Frag }\n`).join('')} }`;

Это плохая идея, и в связанной статье рассказывается, почему, а также ваша конечная точка GraphQL, вероятно, не предназначена для этого. Мы могли бы также отправлять несколько запросов один за другим для каждого продукта, но тогда мы теряем одно из ключевых преимуществ GraphQL по сравнению с REST.

Но: мы обычно оставляем поле для запроса отдельных объектов, потому что просмотр одного элемента обычно является вариантом использования нашего приложения, и мы можем очень быстро ответить на этот запрос. См. последний раздел моего ответа на запросы.

Два других варианта в основном одинаковы

Вариант 1 и Вариант 3 следует последовательно выбирать для всего проекта. Соединение может быть бесполезным при запросе идентификаторов, но оно может помешать возврату ко многим элементам и беспрепятственно интегрироваться с Relay.

Вам также необходимо подумать о том, как затем снова связать идентификаторы во внешнем интерфейсе со значениями. Вы возвращаете элементы в том же порядке, в котором они были запрошены (как известно, например, из Dataloader), или вы запрашиваете идентификаторы объектов, и порядок не имеет значения.

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

Общие фильтры считаются вредными

Как правило, рекомендуется отображать только те запросы, которые действительно необходимы вашему внешнему интерфейсу, как описано в этой ветки Twitter. и Ли Байрон (один из создателей) добавляет , что вы также должны показывать только те запросы, которые вы можете выполнять эффективно. В отличие от этого, Apollo рекомендует не соединять клиентские и серверные реализации, а вместо этого абстрактные схемы. Я думаю, вам придется найти баланс.

Я думаю, что раскрытие очень специфичного объекта фильтра почти так же хорошо, как создание нового поля каждый раз, но это может не так хорошо масштабироваться. Вам нужно будет быстро создавать сложные запросы, и библиотека построителя запросов может оказаться полезной. С другой стороны, если у вас уже есть это — как в вашем примере, продукты могут уже сильно фильтроваться — это может быть очень легко добавить.

Некоторые проекты в дикой природе предлагают расширенные фильтры, такие как Hasura, Prisma и Гэтсби. Поэтому, если вы хотите создать более общие фильтры, вы можете черпать вдохновение из этих проектов.