The Experience Edge schema

The types available in the Experience Edge schema reflect the template definitions of the Sitecore instance that published to it. You can enable strongly-typed template fields by using inline fragments that select fields from specific types.

In the Sitecore back end, you can give the same name to templates and fields. However, in GraphQL, the names of types and fields must be unique. When a naming collision occurs, the item or field item with the newest creation date has _{guid} appended to the name. The creation date is used because the ordering must be stable, and a graph type name must never change after it has been referenced.

Paginated queries and fields in the Experience Edge schema, such as the search query, utilize a cursor-based system to request result pages.

For paginated queries:

Query complexity refers to a numerical score assigned to a GraphQL query based on how resource-intensive it is to execute. This score helps prevent overly complex queries from degrading performance or risking denial-of-service. Experience Edge queries have a complexity limit. We recommend you test your query before using it in a runtime environment, to make sure it meets the complexity requirements. If your query is too complex, try the following:

Because of an inherent difference in data structure, complexity is calculated differently between the delivery endpoint and preview endpoint (the content management back end). We have introduced default settings so that complexity calculations will match as closely as possible; however, it's impossible to match them completely.

Some configuration options for the preview endpoint are available in the sitecore.config file, in the complexityConfiguration object:

<!-- 
  COMPLEXITY CONFIGURATION
  It is possible to conduct denial of service attacks by constructing extremely expensive to run GraphQL queries.
  The complexity configuration defeats that by limiting how complex of a query will be run.
  
  maxDepth: the maximum nesting depth in a query. maxDepth values lower than 15 will prevent /ui from running.  
  fieldImpact: the average impact of adding a list field to a query (e.g. how many average items it would return).
  maxComplexity: the maximum field impact a query can have before it's rejected. With a fieldImpact at 2, values of maxComplexity less than 250 will prevent /ui from running.
-->
<complexityConfiguration type="GraphQL.Validation.Complexity.ComplexityConfiguration, GraphQL" patch:source="Mvp.Environment.GraphQL.config">
  <maxDepth>15</maxDepth>
  <maxComplexity>10000</maxComplexity>
  <fieldImpact>2</fieldImpact>
</complexityConfiguration>

Alternatively, in non-production environments, you can raise the complexity limitation of the preview endpoint to large numbers that can’t be reached, and run queries to estimate what the cost would be for Experience Edge (delivery) queries in a production environment.

In Experience Edge, you can use the GraphQL search query on the special fields listed in the following table. When querying templates, you can only query user-defined fields and the following special fields. For example, you can query the user-defined title field of the sample item template, but not _Sortorder.

query Search {
  search(
    where: {
      name: "title",
      value: "Sitecore",
      operator: CONTAINS
    }
  ) {
    results {
      id
      name
    }
  }
}

query Search {
  search(
    where: {
      name: "_parent"
      value: "110D559FDEA542EA9C1C8A5DF7E70EF9"
      operator: EQ
    }
  ) {
    results {
      id
      name
    }
  }
}

query Search {
  search(
    where: {
      AND: [
        {
          name: "_parent"
          value: "110D559FDEA542EA9C1C8A5DF7E70EF9"
          operator: EQ
        },
        {
          name: "title"
          value: "another"
          operator: CONTAINS
        }
      ]
    }
  ) {
    results {
      id
      name
    }
  }
}

You can apply changes to an image directly in Edge. The following options are supported for image manipulation: