Поддержка возражений `$ formatJson` в ApolloServer

Question

Я большой поклонник Objection.js и GraphQL , и я пытаюсь заставить их работать вместе для нового API в моем бизнесе. К сожалению, у меня возникли некоторые трудности.

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

$ formatJson , дляНапример, может использоваться для изменения свойств Date, которые являются объектами JS Date при работе с моделью, но превращаются в строки ISO при отправке в ответе:

$formatJson(json: Pojo): Pojo {
    json = super.$formatJson(json);
    if (json.lastActive) json.lastActive = json.lastActive.toISOString();
    return json;
}

Этот метод вызывается в* метод экземпляра #toJSON, который обычно вызывается при строковом преобразовании, как описано здесь .

ApolloServer (в частности, apollo-server-koa , который я использую) неоднако, непосредственно приведите в порядок эти экземпляры модели. Кажется, он (разумно) копирует подмножества свойств в новые объекты, отделяя данные от методов его экземпляров. Таким образом, #$formatJson никогда не будет вызываться, и мои Даты возвращаются как временные метки, поскольку именно так даты JS по умолчанию преобразуются в строку. копирование свойств из их возвращаемых значений. Я посмотрел formatResponse здесь , но похоже, что он получает данные после того, как они уже отделены от классов Model.

Может ли кто-нибудь, кто знаком с ApolloServer, указать мнев правильном направлении? Есть ли какой-нибудь плагин API, который мне нужно изучить?

Я нашел objection-graphql , который очень крутой, но, похоже, он справляется с этим, обрабатывая весь запрос сверху-уровень распознавания и рекурсивный вызов #toJSON на всем, прежде чем распознаватель даже вернется. Решатели по умолчанию выбирают все остальное из загруженной структуры. Очень круто, но не похоже, что он будет достаточно гибким для моих нужд. На самом деле я просто хочу решить эту конкретную проблему, а не волшебство от всего моего API. : \