вводить динамически построенный контекст в GraphQL? - PullRequest
Новая
       7

вводить динамически построенный контекст в GraphQL?

0 голосов
/ 08 ноября 2019

У меня есть первый сервер GraphQL на SDL, который я пытаюсь постепенно преобразовывать в TypeScript. Чтобы сделать подход, основанный на SDL, более модульным, я использую несколько глобусов для объединения SDL DocumentNode s, распознавателей, загрузчиков данных, классов моделей и т. Д. Перед запуском сервера Apollo. Мне нравится этот метод, потому что он устраняет необходимость в десятках операторов import в нескольких местах и ​​является немного более устойчивым к изменениям имен файлов (при условии, что эти имена файлов все еще соответствуют шаблону glob). Это означает, что объект context, передаваемый на сервер Apollo, создается динамически, и в конечном итоге он становится проблемой для TypeScript на уровне распознавателя / загрузчика данных, поскольку TypeScript не может заранее знать форму объекта context.

Итак, если у меня есть класс ThingModel, такой как 

class ThingModel {
  static async get( args ) { ... }
}

, прикрепленный к объекту, назначенному для context.models (который может иметь свой собственный тип), распознаватель, такой как 

async function fetchMyThing( parent, args, context, info ) {
  return await context.models.ThingModel.get( args );
}

не сможет вывести тип ThingModel.

Я предполагаю, что смогу получить вывод типа, который хочу, если смогу напечатать весь объект context, например что-то вроде

interface IContext {
  models: IModels
}

interface IModels {
  ThingModel: typeof ThingModel
}

const context : IContext = {
  ...
}

// now pass context to server initialization

Есть ли (хороший) способ добиться этого без необходимости возвращаться к ручному import обращению ко всем частям моего контекста (чтобы я мог затем объявить интерфейсы)?

FWIW, я должен упомянуть, что мы не привязаны к GraphQL-первому SDL и сначала решим перейти на GraphQL-первый код (это все еще небольшой проект) через GraphQL Nexus или TypeGraphQL, так что если онифреймворки обеспечивают эффективное «распространение типов», что, вероятно, было бы еще одним аргументом в пользу перехода на GraphQL-код в первую очередь.

Спасибо!

...