Replies: 2 comments
-
What's your current process for building and injecting the schema at runtime? I use the example they provide that allows modularity of gql files: import path from 'path'
import { loadFilesSync } from '@graphql-tools/load-files'
import { mergeTypeDefs } from '@graphql-tools/merge'
const typesDefsArray = loadFilesSync(
path.join(__dirname, '../resolvers/**/*.graphql'),
{ recursive: true }
)
export const typeDefs = mergeTypeDefs(typesDefsArray) But then when the project is built and bundled into one file, the import I know I can rewrite stuff at build time and adjust the imports and do things like that, but I'm wondering if you know a simpler way? |
Beta Was this translation helpful? Give feedback.
-
I'm also running into issues with What I'm seeing is that a simple GraphQL server with some data fetching and transformation logic can respond in around I did find a way of somewhat mitigating this by storing the stitched schema as a global variable, which is used between Cloudflare worker runs. That doesn't work for very long before a cold start will get hit again. I believe I could actually make a simple change to cache |
Beta Was this translation helpful? Give feedback.
-
Hey there,
we're using
graphql-tools
stitching to build an API Gateway that combines several 3rd party GraphQL and OpenApi APIs. With a growing number of (large-ish 1) APIs, we notice the time required bystitchSchemas
has gone up significantly, which makes sense but also interferes with our ability to scale in an elastic manner.Now we're wondering whether we can move stitching/resolver generation to the build process and only attach resolvers when starting up. We haven't been able to find any reference for that so far.
Does this approach make sense? Has anyone already done it?
Thanks!
Footnotes
I'm looking at you, Atlassian and Salesforce. ↩
Beta Was this translation helpful? Give feedback.
All reactions