How to handle schema contracts for local development that does not depend on CDN

[kdawgwilk]

How is everyone handling developing supergraph schemas with schema contracts for local development? From what I can tell, it seems like people would have to publish their supergraph schema to Hive and have it generate a variant for each of the contracts. And then I'd have to point my local code gen at that CDN version that's pointed at the schema contract variants.

And that doesn't seem very feasible when trying to iterate for local dev on schema changes. Is there a better way to handle this?

[n1ru4l]

Hey @kdawgwilk!

You can use the @theguild/federation-composition library for composing the schema of a supergraph without the need of a schema registry.

Here is a small example:

import { composeSchemaContract } from '@theguild/federation-composition';

const compositionResult = composeSchemaContract(
  [
    {
      name: 'users',
      typeDefs,
    },
    {
      name: 'products',
      typeDefs,
    },
  ],
  {
    // "public" is the tag name
    include: new Set(['public']),
    exclude: new Set(),
  },
  // whether unreachable types should be stripped out.
  true,
);

if (compositionResult.errors) {
  throw new Error(
    'Could not create public GraphQL schema.\nEncountered the following composition errors:\n' +
      compositionResult.errors.map(error => `- ${error.message}`).join('\n'),
  );
}

console.log(
  // contract supergraph SDL
  compositionResult.supergraphSdl,
  // GraphQL schema SDL as served by router/gateway for this contract
  compositionResult.publicSdl
);

---

Aside from that, we also have a local subgraph development mode within our CLI. This allows you to replace one local service and compose it with the other services in the schema registry. This currently does not support outputting schema contracts. Would built-in support for composing schema contracts there be useful to you?