Разница между graphql-tools между mergeSchemas и makeExecutableSchema
Итак, причина, по которой я задаю этот вопрос, заключается в том, что я могу заставить оба из них вернуть рабочий результат, просто заменив один или другой. Так какой из них правильнее использовать и почему?
Каковы их цели в отношении схем?
import { mergeSchemas } from 'graphql-tools'
import bookSchema from './book/schema/book.gql'
import bookResolver from './book/resolvers/book'
export const schema = mergeSchemas({
schemas: [bookSchema],
resolvers: [bookResolver]
})
import { makeExecutableSchema } from 'graphql-tools'
import bookSchema from './book/schema/book.gql'
import bookResolver from './book/resolvers/book'
export const schema = makeExecutableSchema({
typeDefs: [bookSchema],
resolvers: [bookResolver]
})
Оба этих примера работают и возвращают желаемый результат. Я считаю, что здесь правильно использовать makeExecutableSchema, но не уверен, почему первый сработает?
РЕДАКТИРОВАТЬ На всякий случай было бы неплохо иметь типы/преобразователи:
typeDefs
type Query {
book(id: String!): Book
bookList: [Book]
}
type Book {
id: String
name: String
genre: String
}
Резольверы
export default {
Query: {
book: () => {
return {
id: `1`,
name: `name`,
genre: `scary`
}
},
bookList: () => {
return [
{ id: `1`, name: `name`, genre: `scary` },
{ id: `2`, name: `name`, genre: `scary` }
]
}
}
}
Запрос выполнен
query {
bookList{
id
name
genre
}
}
Результат
{
"data": {
"bookList": [
{
"id": "1",
"name": "name",
"genre": "scary"
},
{
"id": "2",
"name": "name",
"genre": "scary"
}
]
}
}
Ответы 3
mergeSchemas в первую очередь предназначен для использования в коде объединения сшивание схемы, нет для одной схемы, которую вы выбрали для разделения в организационных целях.
Сшивание схемы чаще всего выполняется, когда у вас есть несколько микросервисов, каждый из которых предоставляет конечную точку GraphQL. Вы можете использовать извлекать схемы из каждой конечной точки, а затем использовать mergeSchemas для создания одной службы GraphQL, которая соответствующим образом делегирует запросы каждой микрослужбе. Технически сшивание схем также можно использовать для расширения некоторых существующих API или для создания нескольких сервисов из базовой схемы, хотя я полагаю, что такие варианты использования менее распространены.
Если вы разрабатываете единую автономную службу GraphQL, вам следует придерживаться makeExecutableSchema. makeExecutableSchema — это то, что на самом деле позволяет вам использовать язык определения схем для создания вашей схемы. mergeSchemas — это относительно новый API и имеет ряд открытых вопросов, особенно в отношении того, как обрабатываются директивы. Если вам не нужна функциональность, предоставляемая mergeSchemas, а именно, вы на самом деле не объединяете отдельные схемы, не используйте ее.
Да makeExecutableSchema creates a GraphQL.js GraphQLSchema instance from GraphQL schema language в соответствии с Документы по GraphQL-инструментам Так что, если вы создаете автономный автономный сервис GrpaphQL, это то, что вам нужно.
Но если вы хотите объединить несколько сервисов GraphQL, вы можете рассмотреть несколько различных стратегий, таких как объединение схем, объединение схем из инструментов graphql или федерация из apollo (вероятно, есть и другие).
Поскольку я попал сюда, когда искал, в чем разница между stitching и merging, я хотел указать, что это не одно и то же. Здесь — это ответ, который я получил на этот вопрос на github graphql-tools.
Сшивка схемы создает прокси-схему поверх различных независимых подсхем, поэтому части этой схемы выполняются с использованием GraphQLJS внутри. Это полезно для создания такой архитектуры, как микросервисы.
Слияние схем создает новую схему путем слияния извлеченных из них определений типов и распознавателей, поэтому будет один слой выполнения.
Первый сохраняет отдельные схемы, а второй нет. Вариант использования первого — объединение нескольких удаленных API-интерфейсов GraphQL (микросервисов), а второй — объединение локальных схем.
Обратите внимание, что в более новых версиях инструментов GraphQL функция сшивания была переименована
stitchSchemas, аmergeSchemasтеперь делает то, что вы ожидаете, объединяя схемы напрямую без прокси-слоя (на основе функциональности набора инструментов GraphQL). API для сшивания схем был значительно улучшен, но вам по-прежнему следует избегать добавления прокси-слоя (если вам это не нужно).