Metadata format reference¶
Table of contents
Introduction¶
With config v3
, the metadata that is exported from the server by the CLI is a
directory of multiple files/directories.
Note
For config v2
, see Metadata format reference (config v2).
Metadata directory format¶
The following files will be generated in the metadata/
directory of your project:
Note
The output of the export_metadata API is a JSON version of the metadata files.
actions.graphql¶
The actions.graphql
file contains all the action definitions and custom type definitions.
Example: A query action called greet
and two custom types called SampleInput
and SampleOutput
.
type Query {
greet (
arg1: SampleInput!
): SampleOutput
}
input SampleInput {
username : String!
}
type SampleOutput {
greetings : String!
}
actions.yaml¶
The actions.yaml
file contains metadata related to actions.
Example: An action called greet
with the handler
set to <base_url>/greet
and two custom types called SampleInput
and SampleOutput
.
actions:
- name: greet
definition:
kind: ""
handler: <base_url>/greet
forward_client_headers: true
headers:
- value: application/json
name: Content-Type
custom_types:
enums: []
input_objects:
- name: SampleInput
objects:
- name: SampleOutput
scalars: []
Example: Same example as above but with the base URL of the handler
passed as an environment variable.
actions:
- name: greet
definition:
kind: ""
handler: '{{ACTION_BASE_URL}}/greet'
forward_client_headers: true
headers:
- value: application/json
name: Content-Type
custom_types:
enums: []
input_objects:
- name: SampleInput
objects:
- name: SampleOutput
scalars: []
allow_list.yaml¶
The allow_list.yaml
file contains the metadata related to allow lists.
Example: A query collection called allowed-queries
set as the allow-list.
- collection: allowed-queries
cron_triggers.yaml¶
The cron_triggers.yaml
file contains metadata related to cron triggers.
The webhook
can be an HTTP endpoint or an environment variable containing the HTTP endpoint.
Example: A cron trigger called test-trigger
.
- name: test-trigger
webhook: <webhook-url>
schedule: 0 12 * * 1-5
include_in_metadata: true
payload: {}
retry_conf:
num_retries: 1
timeout_seconds: 60
tolerance_seconds: 21600
retry_interval_seconds: 10
Note
The metadata about a cron trigger will not be stored if Include this trigger in Hasura Metadata
is disabled in the advanced option of events
on the console or include_in_metadata
is passed as false
via the API.
query_collections.yaml¶
The query_collections.yaml
file conatins metadata information about query collections.
Example: A query collection called sample-collection
which contains two queries test
and test2
.
- name: sample-collection
definition:
queries:
- name: test
query: |-
query test {
books {
id
author_id
title
}
}
- name: test2
query: |-
query test2 {
authors{
id
author_name
}
}
remote_schemas.yaml¶
The remote_schemas.yaml
file contains the metadata related to remote schemas.
Example: A remote schema called my-remote-schema
with URL <remote-schema-url>
.
- name: my-remote-schema
definition:
url: <remote-schema-url>
timeout_seconds: 40
Example: A remote schema called my-remote-schema
with URL passed as environment variable.
- name: my-remote-schema
definition:
url_from_env: REMOTE_SCHEMA
timeout_seconds: 40
databases¶
metadata
├── actions.graphql
├── actions.yaml
├── allow_list.yaml
├── cron_triggers.yaml
├── databases
│ ├── databases.yaml
│ └── default
│ └── tables
│ ├── public_t1.yaml
├── query_collections.yaml
├── remote_schemas.yaml
└── version.yaml
databases.yaml¶
- name: default
configuration:
connection_info:
database_url: <database_url>
pool_settings:
idle_timeout: 180
max_connections: 50
retries: 1
tables:
- "!include public_t1.yaml"
functions: []
Note
database_url
can be set from an environment variable
by specifying it as:
database_url:
from_env: SOME_ENVIRONMENT_VARIABLE
public_t1.yaml¶
table:
name: t1
schema: public