Это их способ и он явно не универсальный. Для обертки коллекций есть пагинация, которая покрывает основные нужды.

Ну и нужно понимать, что у них там ноды коллекций, а не энтети. Энтети как раз отдельно и стандартно. Т.е. это у них абстракция над коллекциями.

Это делают не просто. В Relay так, а в Аполло рекомендовано. Делают interface, чтобы сущностый тип всегда был приведён к одному виду. Тогда ваш id created updated находится в узле Node, далее конретный тип использует интерфейс. Тогда в схеме видно сущности и можна легко расширить все сущности при необходимости. Вы расширяете узел, а далее сразу увидите где отвалились классы и добавляете уже в них.
https://relay.dev/graphql/objectidentification.htm

А вот обоснование: To provide options for GraphQL clients to elegantly handle for caching and data refetching GraphQL servers need to expose object identifiers in a standardized way.

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

Да, соглашусь

Понятно, я в целом это все понимаю, но лишний апрув хотел получить. Ибо теория это одно, а на деле с огромным grpahql я не работал

Этот вопрос древний, он про правильно, а миф гласит, что если кто-то сделает неправильно, случится нечто, а оно как бы пугает. У некоторых это со школы, у других из левого кармана. А в жизни оно бывает проще, есть задача передать два байта и если два байта передано, то хорошо. Можно быстрее передать, можно медленее, удобнее или неудобнее, но это уже детали... Слово правильно неприменимо для реальной жизни, лучше мыслить категориями лучше, хуже, быстрее, медленее, проще, сложнее... А правильно, оно бывает неправильно для одних, а для других смотришь правильно)

Интерфейс Node был еще в 2015-16 годах завезен в Relay Classic и это чисто релеевская приблуда.

Мотивация Фейсбука: обновлять локальный кэш на автомате. Зная только этот ID можно дернуть ентити через поле Query.node: query { node(id: BASE64_ID) { …on EntityType{ field1, field2, field3 } }}.

Реализация: графкуэльный ID исторически это base64(entityName + ‘:’ entityId). Такой формат позволяет десереализировать ID в резолвере Query.node на сервере. И там ты уже знаешь что за ентити и с каким айди нужны пользователю чтоб вытянуть из базы (хотя никто не мешал им вытягивать имя типа в фрагменте из 4го аргумента info в методе resolve. Но видимо тогда не доперли. Вот вам и base64 как костыль)

Проблемы интерфейса node: клиентское двигло должно при билде нагенереть себе запросов с фрагментами `query { node(id: BASE64_ID) { …on EntityType{ field1, field2, field3 } }}. Сразу знать название ентити и набор полей. чтоб правильно составить эти фрагменты. А это практически нереально сделать. Поэтому обычно такие запросы герятся в рантайме, а это проблемы
- нет возможности использовать persistented query
- дыра по безопасности, очень легко проморгать проверку того, что Entity:123 нельзя показывать этому пользователю. Правильная реализация резолвера Query.node становится сложной задачей, плюс к этому мало какому клиенту эта приблуда нужна. Нужна наверное если в вашей бизнес логике это рельно руками заведено.

Текущее положение: “Node interface + base64ID” в практике не показал своей пользы. В самом коде RelayModern я чет не припомню чтоб его где-то использовали. В Аполло обходятся __typename (имя типа) и id (реальный айдишник ентити из базы) – и это сейчас наиболее удобный вариант.

———

Резюме:
- передавать id в base64 это уже никому ненужная приблуда (правда может быть что, это архитектурное решение и вы специально решили разнести айдишники, чтоб где-нибудь не опечататься, иметь хорошие логи и пр.)
- сам Node интерфейс может использоваться для выделения из тьмы Output-Типов, которые являются Entity (но это как стандарт в туллингах нигде не используется). Т.е. юзаете для себя чисто for fun или для своих узких задач.

Итог: в 98% приложений вам интерфейс Node и base64ID не нужны.

Хотел написать коротко, получилось длинно. Если где ошибся своим мнением - поправьте пжлста. И я тогда утащу это в виде статейки к себе в репку.

@nodkz давно хочу поконтртбьютить в тот сайт, ибо идей и ищью интересных полно. Но все никак нет времени за другими задачами (

Отличный ответ!

Чего сильно не хватает, так это разбора, хотя бы на примере Apollo server, всех стратегий авторизации итд.

Как, что, зачем почему, где какие плюсы, какие минусы, вот это вот так пишется в аполло, а на остальные думаю уже разберутся.
А то это пока единственный вопрос который я не могу ответить внятно. Чтобы и дев опыт клиента был ок, тоесть кодогенерация итд

Тоесть интроспекция не может меняться от клиента к клиенту, но как при этом это сделать, чтобы не все поля опциаональными фигачить, это другой вопрос.

Спасибо

Здравствуйте, хочу написать свой  UI клиент для гуманитариев, где можно генерить запросы одной лишь мышкой щёлкая на выпадашки.
Взял ковырять apollo-client - упёрся в чудную функцию graphql-tag:
import gql from "graphql-tag";
const GET_VALUES = gql`***`
*** - сюда (в апосторофы!) пишется почти готовый запрос, можно пробросить параметры но нельзя полностью сложить string на стороне и впихнуть, а мне критически надо, может что-то подскажете?
смотрю клиент на .net там можно разгуляться, но подвис с русскоязычными полями - не знаю как поставить кодировку в NewtonsoftJsonSerializer

Писать такое с нуля немного глупо когда есть OneGraph graphiql

Там как раз таки выпадашки

И поиск и все что хочешь. Клик клик клик, автокомплит и все такое в выпадашках

Я бы с удовольствием заставил энд-юзеров работать с тем, что есть,
но это не в моей власти)
За наводку спасибо, поковыряю

Возможно вы про это?

fetch('/graphql', {
 method: 'POST',
 headers: {
   'Content-Type': 'application/json',
   'Accept': 'application/json',
 },
 body: JSON.stringify({query: "{ hello }"})
})
 .then(r => r.json())
 .then(data => console.log('data returned:', data));

В этом руководстве можна посмотреть детальнее как https://graphql.org/graphql-js/graphql-clients/