Ок, спасибо

моя жизнь разделилась на до и после

О, это вообще огонь

да, огнище, теперь если апи меняется, после генерации видно несоответствие

Есть такой же пример с гоушкой?

Каким способом кодогенерации для TypeScript на сервере вы пользуетесь? Просто я взял graphql-codegen и скорость билда сервера стала больше 7 минут.

Само использование сгенерированных типов достаточно простое

// category.resolvers.ts
import { Resolvers } from '../types';

export const resolvers: Resolvers = {...}

Генерируется вот такой тип с описанием резоверов.

// types.ts
export type Resolvers<ContextType = IGraphQLContext> = ResolversObject<{
  Query?: QueryResolvers<ContextType>,
  Mutation?: MutationResolvers<ContextType>,
  Category?: CategoryResolvers<ContextType>,
  // ...
}

С диагностическими данными TS не всё однозначно

I/O Read time:               0.07s
Parse time:                  0.94s
Program time:                2.45s
Bind time:                   0.75s
Check time:                  5.55s
transformTime time:        509.14s
Source Map time:             0.17s
commentTime time:            1.01s
printTime time:            514.87s
Emit time:                 514.89s
I/O Write time:              0.15s
Total time:                523.64s

Очень понравились рекомендации по созданию GRAPHQL-схем от @nodkz . А как считаете, в query тоже следует передавать статус и ошибки, как в мутациях? Ведь там тоже может встретиться какая-нибудь 404 или 403 ошибка

Добрый день.
Подскажите где почитать: пришёл GraphQL-запрос, но он не проходит авторизацию.

Отвечать http 200 + GraphQL response с ошибкой, или http 403 и plain text с сообщением об ошибке?

Спасибо.

Как это вообще принято делать?

На сколько я помню, в спеке ничего про коды нет. То есть правильнее писать просто ошибки в ответе. Если фронтам, системе логирования или кому-нибудь ещё будет удобное HTTP коды получать, то можно отправлять и их.

Всё сильно зависит от клиента. Если клиенту в списках важно показывать не найдено и нет доступа, то надо пилить. Если клиенту не важны такие данные в списках, то не нужно.

Мы у себя возвращаем 200 и в теле ответа возвращаем джейсон с псевдо ответом graphql errors.0

А уже клиент парсит это ошибку и редиректит клиента на страницу авторизации.

Это я про 401 и аутентификацию

Про 403 зависит от потребностей клиента.

Обычно тупо null возвращаем в дата, а в еррорс пишем ошибку 403

Но хттп-код 200.

Спасибо.

Как лучше хранить данные когда существует какаято Entity и у нее часть полей (цены) имеют период жизни пока активен текущий route, а часть полей не меняются и должны после запроса с сервера оставаться в кеше

Запрос на данном рауте тащит целиком Entity с ценами

выделить поля цен в отдельную Entity?

а что за рекомендации?