-
Notifications
You must be signed in to change notification settings - Fork 411
How to stitch schemas with Nest@5? #76
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi, is there an undocumented way of doing this currently? Wondering if I should dig deeper or wait. Thanks! |
what about apollo federation schema ? (https://blog.apollographql.com/apollo-federation-f260cf525d21) , is there some documentation on how to implement it with Nestjs ? thanks! |
an example of apollo federation and nest microservices would be fucking awesome. |
Hi, I do have apollo federation setup, but the revolvers don't work anymore. That seems to be the issue. How to make the resolvers work. |
I have same problem. It would be nice to get sample code for stitching the schema. |
I did a PR guys I'm currently putting together an example repository with kubernetes and prisma 😁 |
I had solved schema stitching problem by using transform method. here my code
|
Schema stitching is deprecated |
@kamilmysliwiec Can I ask why schema stitching is deprecated? Trying to implement something and so I want to make sure I understand why it was deprecated and what should be its replacement. |
I don't think it's accurate to say schema stitching is deprecated. The Although there is a lot of crossover, Schema Stitching and Apollo Federation serve different use cases. The key difference is that Apollo Federation requires modifications to the underlying schema(s), whereas Stitching does not. This allows Stitching to be used to wrap together remote schemas that you don't have the ability to modify, such as APIs operated by third parties. I am pleased to see that It would be even better if link-level resolvers (i.e. resolvers for extended type fields that operate on the stitched schema gateway and pass down delegated queries to subschemas) could be written in the canonical NestJS style using |
@sgarner Bless you... This inform is super useful to keep building our apis. Thank you so much for the response! |
Does this work in Nestjs 7?? |
For anyone finding this issue in 2021, stitching does work in NestJS 7. It took me a couple days to wrap my head around it, but in general you can follow the graphql-tools instructions for stitching remote schemas. Here's a simplified example of how to stitch remote schemas into a gateway: import { AsyncExecutor, ExecutionRequest, observableToAsyncIterable, Executor } from '@graphql-tools/utils';
import { GqlModuleOptions, GqlOptionsFactory } from '@nestjs/graphql';
import { Injectable } from '@nestjs/common';
import { introspectSchema } from '@graphql-tools/wrap';
import { stitchSchemas } from '@graphql-tools/stitch';
import { SubschemaConfig } from '@graphql-tools/delegate';
import { GraphQLError, print } from 'graphql';
import nodeFetch from 'node-fetch';
import * as ws from 'ws';
// This example uses subscriptions-transport-ws. If your subschema APIs support graphql-ws, use that instead.
import { SubscriptionClient } from 'subscriptions-transport-ws';
import { WebSocketLink } from 'apollo-link-ws';
function buildExecutor(url: string) {
return async (request: ExecutionRequest) => {
// Feel free to use your favorite alternative to node-fetch here instead
const fetchResult = await nodeFetch(url, {
method: 'POST',
headers: {
'Content-Type': 'application/json',
},
body: JSON.stringify({
query: print(request.document),
variables: request.variables,
})
});
return await fetchResult.json();
};
}
function buildSubscriber(url: string): Subscriber {
const subscriptionClient = new SubscriptionClient(
url,
{ reconnect: true, lazy: true },
ws
);
return (request: ExecutionRequest) => {
const wsLink = new WebSocketLink(subscriptionClient);
const result = wsLink.request({
query: request.document,
variables: request.variables || {},
operationName: request.operationName,
extensions: {},
getContext: () => ({}),
setContext: (c) => c,
toKey: () => 'someKey',
});
return observableToAsyncIterable(result);
};
}
function buildRemoteExecutor(
httpUrl: string,
wsUrl: string
): Executor {
const subscribe = buildSubscriber(wsUrl);
const execute = buildExecutor(httpUrl);
return async (request: ExecutionRequest) => {
if (request.operationType === 'subscription') {
return subscribe(request);
}
return execute(httpUrl, request, headers);
};
}
@Injectable()
export class GqlConfigService implements GqlOptionsFactory {
async createGqlOptions(): Promise<GqlModuleOptions> {
const executors = [
this.buildRemoteExecutor('https://remote-server-a.com/graphql', 'wss://remote-server-a.com/graphql'),
this.buildRemoteExecutor('https://remote-server-b.com/graphql', 'wss://remote-server-b.com/graphql')
];
const subschemas = await Promise.all(
executors.map(async (executor): Promise<SubschemaConfig> => {
return {
schema: await introspectSchema(remoteExecutor),
executor: remoteExecutor,
};
})
);
const schema = stitchSchemas({ subschemas });
return {
schema,
debug: true,
playground: {
env: this.env,
endpoint: '/graphql',
subscriptionEndpoint: '/subscriptions',
},
tracing: true,
installSubscriptionHandlers: true,
introspection: true,
subscriptions: {
path: '/subscriptions',
keepAlive: 10000,
}
};
}
} Some of the servers I'm working with are still using the old |
I'm submitting a...
Current behavior
Expected behavior
❌ injecting graphql factory
❌ accessing local schema
Minimal reproduction of the problem with instructions
What is the motivation / use case for changing the behavior?
schema stitching with nest@5
Environment
The text was updated successfully, but these errors were encountered: