Легко перейти на Postgraphile (несколько экземпляров ApolloClient) - PullRequest
Новая
       18

Легко перейти на Postgraphile (несколько экземпляров ApolloClient)

0 голосов
/ 22 октября 2018

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

Есть ли способ интегрировать Postgraphile по частям, используя мою старую схему GraphQL, описаннуюруками работает?

Итак, теперь у меня есть следующий код инициализации: 

function createApolloLink(){
  return createHttpLink({
    uri: '/graphql',
    credentials: 'same-origin'
  });
}

function create(){
  return new ApolloClient({
    link: createApolloLink(),
    ssrMode: !process.browser, // eslint-disable-line
    cache: new InMemoryCache(),
    connectToDevTools: process.browser
  });
}

Как использовать одно нормализованное хранилище (на стороне клиента) и подключиться ко второй точке API, управляемой Postgraphile, например /graphql2?

1 Ответ

0 голосов
/ 22 октября 2018

Как правило, вашему клиенту GraphQL не нужно об этом думать - его следует обрабатывать на стороне сервера.

Существует ряд методов, которые можно использовать для решения этой проблемы на стороне сервера:

Схема сшивания

Схема сшивания - простой подход к вашей проблеме - возьмите старую схему и объедините ее с вашей схемой PostGraphile;таким образом, когда клиенты общаются с /graphql, они имеют доступ к обеим схемам.Затем вы можете пометить все в старой схеме как устаревшее и постепенно прекратить использование.Однако, если вы можете, я бы порекомендовал вам использовать плагин PostGraphile ...

Плагин PostGraphile

PostGraphile построен на основе системы плагинов, и вы можете использовать что-то вроде makeExtendSchemaPlugin, чтобы смешать вашу старую схему GraphQL с PostGraphile.Это задокументировано здесь: https://www.graphile.org/postgraphile/make-extend-schema-plugin/, но если ваши старые типы / преобразователи реализованы с помощью чего-то вроде graphql-tools, это, вероятно, самый простой способ начать работу: 

const { makeExtendSchemaPlugin, gql } = require('graphile-utils');

const typeDefs = gql`\
type OldType1 {
  field1: Int!
  field2: String
}
extend type Query {
  oldField1: OldType1
  oldField2: OldType2
}
`;

const resolvers = {
  Query: {
    oldField1(/*...*/) {
      /* old logic here */
    },
    //...
  },
};

const AddOldSchemaPlugin = makeExtendSchemaPlugin(
  build => ({
    typeDefs,
    resolvers,
  })
);

module.exports = AddOldSchemaPlugin;

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

Делегирование схемы

Используя этот подход, вы создаете свою собственную новую схему GraphQL, которая затем«делегирует» другим схемам GraphQL (устаревшей и созданной PostGraphile).Это добавляет небольшую задержку, но дает вам гораздо больший контроль над окончательной формой вашей схемы GraphQL, хотя с этой возможностью возникает большая ответственность - если вы сделаете опечатку, вам придется поддерживать эту опечатку в течение длительного времени!Лично я предпочитаю подход сгенерированной схемы, используемый PostGraphile.

Однако, чтобы ответить на ваш вопрос по запросу, Apollo Link имеет функцию «контекста», которая позволяет вам изменять способ выполнения запроса.Обычно это используется для добавления заголовков, но вы также можете использовать его для переопределения URI, чтобы определить, куда может идти запрос.Я никогда не делал этого сам, но я не удивлюсь, если бы была ссылка Apollo, которую вы можете использовать, которая будет автоматически переключаться в зависимости от клиентской директивы или даже от имени поля.

https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http#context

...