Feature Request: Provide mesh config programmatically via an API

[angelsvirkov]

Hello wonderful team. I have the following idea for a feature which I believe would increase the usability of graphql-mesh.

Description

In the following I would refer to using graphql-mesh not as a standalone server but as part of an existing server / existing codebase. The idea is that graphql-mesh exposes an API or an option inside of findAndParseConfig() (not 100% sure about it) function to override or simply use configuration which is a javascript object, in which all individual path references are gone but instead replaced with real functions that are programmatically imported in whatever codebase is using graphql-mesh.

In other words:

Following the inversion of control principle, I would like to supply to graphql-mesh resolver functions from my project's ecosystem, rather than letting graphql-mesh load / import those on its own.

Example use case

My team and I would really like to use graphql-mesh inside of our existing server as anything else is not an option for us at the moment. However, our existing server is using specific webpack development and production configurations. At the end, we deploy a simple bundle.js which is a ready-made executable for our server. If we were to use graphql-mesh we would need to maintain a separate configuration system and then somehow inject the additional-resolvers files, for example, next to our bundle.js since graphql-mesh is loading those internally. It would be nice to have the option to provide graphql-mesh directly all resolvers instead of letting it import them on it's own.

Further, use case is using development tools such as TS/ FLow/ Jest, Babel, etc.

Proposed solution

Looking at your code I found out that inside findAndParseConfig() you are building couple of key-value-maps (objects) which are a result of importing / loading modules. So I propose that these maps are simply built by an options parameter which is passed somewhere in findAndParseConfig(). I am not sure about the exact details. I could be wrong but I guess you already get what I am trying to achieve. I would also try looking at the source for the exact place where something like this can be implemented.

Example for how it could look like without breaking API

const resolversObj = {
  // ...
}

const queryComposerResolverFn = (next) => (...args) => // ...

const meshConfig = {
  additionalResolvers: resolversObj,
  transforms: {
    resolversComposition: {
      resolver: 'Query.*',
      composer: queryComposerResolverFn
    }
  }
}

findAndParseConfig({
  customConfig: meshConfig
})

I would be happy to hear your feedback about such a feature

[ardatan]

You can use getMesh like this. It's not documented yet but if you're using TypeScript, it will be easy for you to figure it out.

[angelsvirkov]

Thanks for the suggested solution. I somehow missed it before. However I took a look now and I can say it partially covers what I initially suggested. It looks like the additionalResolvers is a map of functions, which is exactly what I needed.

However, the transforms array contains object configs which are still using the non-resolved composer strings. Example when debugging the code:

// transforms object
...
{
  composer: "./src/isNotAuth".
  resolver: "Mutation.*"
}

So the actual import of a module happens inside getMesh() and in particular the ResolversCompositionTransform class at https://github.com/Urigo/graphql-mesh/blob/584bda4e9188cc8b201b8e75059d507caba7abd5/packages/transforms/resolvers-composition/src/index.ts#L14

Probably a workaround this would be to extend the class with my custom one, where I override the transformSchema method. Nevertheless, it's probably more convenient for everyone if there is a built-in support to use the resolved functions already without importing. Maybe a simple conditional check on line 14 would suffice?

resolversComposition[resolver] = typeof composer === 'function' ? composer : loadFromModuleExportExpressionSync(composer, 'default'); // Async is not available 

What do you think @ardatan

[ardatan]

That's what I am thinking of. We should refactor all handlers and transforms to move external module loading logic outside of them. I am not sure about supporting functions as part of initial config because the schema of configuration is generated from GraphQL. But I'll figure it out soon and keep you posted.

[ardatan]

Actually it has been implemented but we haven't documented it yet. React example uses programmatic API. You can take a look at that example until we document it.
https://github.com/Urigo/graphql-mesh/blob/master/examples/openapi-react-weatherbit/src/mesh/getMeshInstance.ts

[angelsvirkov]

Thanks a lot. I tried out the programmatic API and it worked. This is extremely useful for me and my colleagues. So much appreciated!

[wwerner]

It looks like the ^^^ react example was updated to use the declarative approach now.
I haven't been able to find another example, only some using the 'pre-built' mesh.

Am I missing something or is this the way to go about it: Configure mesh through meshrc and then extend the config programatically?

Thanks!

[angelsvirkov]

It looks like the ^^^ react example was updated to use the declarative approach now.

I haven't been able to find another example, only some using the 'pre-built' mesh.

Am I missing something or is this the way to go about it: Configure mesh through meshrc and then extend the config programatically?

Thanks!

GraphQL Mesh could be used programmatically, as well. We've been doing this for the past 2 years. Here is an example repo that could hopefully help you a little bit https://github.com/Kiesen/graphql-mesh-express . Moreover the Mesh Docs have been significantly updated to provide info about the programmatic usage and they might be a better source of help than the given repo. Hope that helps

[wwerner]

Thanks a ton, appreciated!