Alternatives to polling for hot-reload of stitched schemas

[tomasAlabes]

As requested after chatting with support, creating an issue for this. Related to the hot schema reloading section of the guide to schema stitching.

Today the main approach is via polling. But this might not be the smartest option, as many re-stitches will be done without the need for them.

Other possible approaches:

• Doing it on validation errors (might trigger unnecessary stitching if they are valid errors)
• Skip validation and let it go downstream if possible. For the case where the involved schema has no stitching and can be handled completed by the downstream svc (apollo server doesn't let you skip validation)
• If it can be done on-demand by the app, maybe having a refreshSchema() function that we could call to do the stitching logic, instead of us having to encapsulate it on our side (just nice to have)

Apollo Server

If it helps, with Apollo Server you have to do the hack mentioned here to update the schema after re-creating it.

If you can't use gateway/federation for some reasons (subscriptions, typegraphql, etc.) and you want to upgrade schema in runtime for Apollo Server, you can just do this:

      // import set from 'lodash/set'
      // import { mergeSchemas } from 'graphql-tools'
      // apolloServer = new ApolloServer({ schema, ... })
      // createSchema = mergeSchemas({ schemas: [...], ... })

      const schema = await createSchema()
      // Got schema derived data from private ApolloServer method
      // @ts-ignore
      const schemaDerivedData = await apolloServer.generateSchemaDerivedData(
        schema,
      )
      // Set new schema
      set(apolloServer, 'schema', schema)
      // Set new schema derived data
      set(apolloServer, 'schemaDerivedData', schemaDerivedData)

And all refresh stuff will work like a charm

Hope if helps to kick off the brainstorming for alternatives 🧠 😄

[yaacovCR]

Handbook linked above also demonstrates pushing a reload via mutations within that example, and also contains an example with schema registry via git. Go @gmac !!!!!

[gmac]

@tomasAlabes – everything in the handbook implements pretty generic patterns on purpose. There are lots of ways to do any of these techniques, we're just offering some ideas and encourage adapting them to your needs. Perhaps the more relevant chapter for you is the versioning schema releases example, which explores using a Git repo as a central registry. While that example is still written using polling, you could easily modify the pattern to build around a basic redeploy of your gateway app, or a direct mutation made to the stitched schema telling it to reload itself.

FWIW – at my company, we don't do any kind of hot reloading. We simply deploy updates to the gateway app to take changes live. It's more laborious, but nothing happens by accident in the process. I definitely encourage noodling on that versioning and release example and finding what works for you.

[gmac]

@tomasAlabes – following up, I've update the example with a manual mutation example: https://github.com/gmac/schema-stitching-handbook/tree/master/hot-schema-reloading#without-polling

With a mutation like that in place to trigger a reload, you can setup reload calls however you want within your deploy pipelines.