Warpgrapher Config

The Quickstart demonstrated using a string constant to hold the Warpgrapher configuration. It is also possible to read the configuration from a YAML file or to build a configuration programmatically using the configuration module's API. The following three configurations are all equivalent.

String Configuration

The following is the string constant from the Quickstart.

static CONFIG: &str = "
version: 1
model:
  - name: User
    props:
      - name: email
        type: String
        required: false
";

YAML File Configuration

The same configuration can be created in a YAML file, as follows.

config.yaml

version: 1
model:

  User
  - name: User
    props:
      - name: email
        type: String

The configuration can then be loaded and used to set up a Configuration struct.

main.rs

    let config_file = File::open("config.yaml").expect("Could not read file");
    let config = Configuration::try_from(config_file).expect("Failed to parse config file");

Programmatic Configuration

The code below shows the creation of the same configuration programmatically.

    // build warpgrapher config
    let config = Configuration::new(
        1,
        vec![Type::new(
            "User".to_string(),
            vec![Property::new(
                "email".to_string(),
                UsesFilter::all(),
                "String".to_string(),
                false,
                false,
                None,
                None,
            )],
            Vec::new(),
            EndpointsFilter::all(),
        )],
        vec![],
    );

The programmatic version includes some function arguments that do not appear in the YAML versions of the configuration, because they take on default values when omitted from a YAML configuration. For example, the UsesFilter on a property allows granular control over whether a property is included in create, read, update, and delete operations. This allows, among other things, the creation of read-only attributes. Similarly, the EndpointsFilter determines whether the User type has create, read, update, and delete operations exposed in the GraphQL schema. For example, if users are created by a separate account provisioning system, it might be desirable to filter out the create operation, so that the GraphQL schema doesn't allow the possibility of creating new users.