Add GraphQL Custom Resolver extension type

[iksent]

Is it possible to forward a new custom endpoint (https://docs.directus.io/guides/api-endpoints/) to custom GraphQL query?

[rijkvanzanten]

I'm having some trouble understanding what you mean.. What do you mean by forward an endpoint to a custom GraphQL query ?

[rijkvanzanten]

Ahh I see. There's currently no way to add a custom resolver to the GraphQL system

[iksent]

So it’s a discussion about new feature? :)

[rijkvanzanten]

Yeah! Just updated the title/category 🙂

Also got my upvote, cause I think it'd be great to have 🙂

[rijkvanzanten]

Would you be able to share your thoughts on how you think it should ideally work?

I'm assuming you'd specify a "key" that's used in GraphQL, and then a resolve function that gets the graphql info, and maybe an additional context thing that gets the same stuff as a custom hook? 🤔

Maybe something like

export default {
  id: 'my-custom-graphql-extension',
  key: 'example',
  async resolver(source, args, gqlContext, directusContext) {
    // Do whatever
  
    return {
      custom: 'data'
    }
  }

[iksent]

I think it should be something very similar to Strapi’s schema: most likely Key should have full definition with arguments, and not only the name of gql query/mutation.

restaurantsByChef(id: ID, status: RestaurantStatusInput, limit: Int): [Restaurant]!

[8byr0]

Hey there!
(@rijkvanzanten don't worry if you feel like I'm on all graphql topics haha)

I have this feature running locally (quick and dirty POC) but I think we should discuss the data structure before I submit a PR.

Basically I have a simple endpoint with two additional properties: query and mutation (I did not test any mutation but it's the same principle. For the query I started with you snippet above)

module.exports = {
	handler: (router) => {
		router.get('/', (req, res) => res.send('Hello, World!'));
		router.get('/intro', (req, res) => res.send('Nice to meet you.'));
		router.get('/goodbye', (req, res) => res.send('Goodbye!'));
	},
	// This has to be defined, not tested yet
	mutation: {},
	query: {
		id: 'test_enpoint_query',
		key: 'example',
		fields: {
			id: 'Int!',
			firstName: 'String',
			lastName: 'String',
		},
		args: { id: 'Int!' },

		// eslint-disable-next-line no-unused-vars
		async resolver(_, input) {
			// Do whatever
			console.log('In the resolver', input);
			return {
				id: 123,
				firstName: 'String',
				lastName: 'String',
			};
		},
	},
};

In GraphQL service I will then fetch all this properties to build the schema:

	        const extensionManager = getExtensionManager();
		extensionManager.getEndpoints().map((endpoint) => {
			const endpointPath = path.resolve(endpoint.path, endpoint.entrypoint || '');
			const endpointInstance: EndpointConfig | { default: EndpointConfig } = require(endpointPath);

			const mod = getModuleDefault(endpointInstance);

			if (mod.query) {
				// @ts-ignore
				const { id, fields, resolver, args } = mod.query;

				// Todo : show a warning if any of these is not available

				// Create type for endpoint query
				schemaComposer.Query.addFields({
					[id]: {
						type: schemaComposer.createObjectTC({
							name: `Endpoint_${id}`,
							fields,
						}),
						resolve: (_, input) => resolver(_, input),
						...(args && { args }),
					},
				});
			}
		});

What are you thoughts? I still need to figure out how to pass GraphQL and directus contexts to the resolver, as mentioned earlier

[rijkvanzanten]

Interesting! Hadn't considered integrating custom endpoints with this 🤔 Instead of passing in those 4 explicit flags (id/fields/resolver/args), I'm wondering if we should just let the user create that whole object that we're inserting into the schemaComposer query. That would open up a bit more flexibility in what names to give it etc. Also wondering if we should allow to export multiple queries/mutations from a single graphql extension type, just like how we allow registering multiple endpoints in a single extension.

Another thing to consider is that the available fields and configuration can change over time (which is different from most "static" graphql implementations), so I think we should also think through a way where we can allow for dynamically generating the query/mutation into the schema in runtime, instead of only on startup 🤔

[8byr0]

• Manage all on the endpoint side: not sure, if you update graphql-compose dependency to a version w/ breaking changes it will break the endpoint. On the other hand if it's managed by directus developers do not need to worry about this, they're guaranteed that data structure will most likely not change
• export multiple q/m: why not; Since you can create multiple routes in http handler, you could be able to have multiple queries and mutations that could share a common business logic
• dynamic schema: I made my tests in getSchema and it seems like this function is called before every request, right?

[rijkvanzanten]

dynamic schema: I made my tests in getSchema and it seems like this function is called before every request, right?

Yeah, that's correct 👍🏻 Wasn't paying enough attention. Seeing you're calling that example in the graphql service, that part is already tackled

[juanmanuelcarrera]

Hi @8byr0!

Where do you modify the GraphQL service?

Thanks!

[8byr0]

Work in progress here: #9395

[rijkvanzanten]

Heya! Thanks for opening this feature request!

This feature request has received over 15 votes from the community. This means we'll move this feature request to the Under Review state!

The Core team will schedule a meeting to review this request as soon as possible. The discussion will then be approved or denied. You may or may not be invited to join this meeting with the core team.

For more information, see our Feature Request Process.

[ryami333]

How's that review coming along @rijkvanzanten ?