Generating metadata

Introduction

The DDN CLI can auto-generate metadata for your supergraph based on the schema of the sources added via data connectors. You can also manually edit the metadata using an editor.

The Supergraph modeling section has details of the various metadata objects that make up your supergraph.

Generating metadata

Using the CLI

Once you have configured your supergraph and added a connector, you would typically use the following commands on a day-to-day basis to generate and update the supergraph metadata based on the schema of your data source:

• Step 1: Introspect the data source and update the connector schema:

  ddn connector introspect <connector-name>

  This will update the connector configuration based on the data source and update the connector schema in the corresponding DataConnectorLink.

• Step 2: Add models, commands and relationships from the connector schema:

  ddn model add <connector-name> "*"
  ddn command add <connector-name> "*"
  ddn relationship add <connector-name> "*"

  This will create and update metadata objects for the entities in your data source to expose them via the GraphQL API.

  info

  The CLI generates metadata objects based on the generator config defined in the subgraph config file.

• You can then build the supergraph with the new metadata to run with the local engine:

  ddn supergraph build local
  ddn run docker-start

Using an editor

You can also manually add or update the metadata objects using an editor. The Hasura VS code extension assists with authoring metadata manually.

As mentioned in the previous section you would typically use the CLI to generate most of your metadata. That being said you would typically need to manually edit metadata to define permissions and relationships or to customize the metadata auto-generated by the CLI, e.g. to modify descriptions, graphql field names, etc.

Subgraph generator config

The configuration for generating metadata for a subgraph is defined in the generator field of the subgraph config file of the subgraph.

For example,

app/subgraph.yaml

kind: Subgraph
version: v2
definition:
  name: app
  generator:
    rootPath: .
    graphqlRootFieldPrefix: app_
    graphqlTypeNamePrefix: App_
    namingConvention: graphql
  includePaths:
    - metadata
  envMapping:
    ...

The following are the supported configuration options:

rootPath

Defines the directory in which new metadata files are generated. Metadata is generated in the /metadata directory in the defined root path. It is defined relative to the subgraph config file.

Default: . i.e. metadata is generated in the <subgraph-name>/metadata directory

graphqlRootFieldPrefix

Defines the prefix to add to all GraphQL root fields generated for models and commands in the subgraph.

Default: "" i.e. no prefix is added by default

Also see: Rename GraphQL prefixes command

graphqlTypeNamePrefix

Defines the prefix to add to all GraphQL types generated for models and commands in the subgraph.

Default: "" i.e. no prefix is added by default

Also see: Rename GraphQL prefixes command

namingConvention

Defines the naming convention used while generating GraphQL types and root fields generated for models and commands in the subgraph.

Default: graphql

The following are the supported values:

Convention	Description
graphql	Convert the identifier from the data source to the GraphQL naming convention. i.e. PascalCase for types, camelCase for root fields
none	Use the identifier from the data source as is.