Say hello to Web Awesome, the biggest and best library of open-source web components.

Query Complexity

Manage the complexity of queries to improve performance and prevent error responses.

When is a Query Too Complex?

We have a lot of releases, thousand of icons in each, and most icons are available in several familyStyles. So there’s much more that could be queried than is allowed in a single query.

If your query is too complex, you’ll get an error response that explains what is too complex about it. You’ll need to modify your query to select less. You can issue multiple queries that are less complex instead of a single query that’s too complex.

100,000 is the maximum complexity allowed for a single query.

For example, this query is too complex:

query{
 release(version: "6.4.2") {
  icons {
    id
    unicode
    svgs(filter: {familyStyles: [
      {family:CLASSIC, style:SOLID},
      {family:CLASSIC, style:LIGHT},
      {family:CLASSIC, style:REGULAR}
    ]}) {
      width
      height
      pathData
      html
    }
  }
 }
}

It selects all icons in Font Awesome 6.4.2. For each icon, it gets the id and unicode fields, plus svgs for three familySyles: Classic Solid, Classic Light, and Classic Regular. For each of those SVGs, it selects four fields.

Let’s see how this is too complex.

The basic rule of thumb for calculating the complexity of the query is to count 1 for each field that is selected, considering that some of these fields, like icons or svgs represent multiples.

Working from the bottom up:

There are three familyStyles being selected for svgs, so there’s a 3 multiplier on that field. And there are 4 fields selected under svgs. So that means that the svgs field is going to have complexity of 3 * 4 == 12 for each icon.

Each icon also has an id and unicode. So that’s a complexity of 14 for each icon (12 for svgs, plus the other 2).

There are 3,690 icon IDs in Font Awesome 6.4.2; so that’s the multiplier on the icons field for Font Awesome 6.4.2.

Other versions of Font Awesome will have different counts of icons. See Counting Icon IDs vs. Counting Icons below for a query that shows how many icon IDs are in a release.

So the icons field in this query will have a complexity of 51,660.

The release field just counts as 1.

So the total complexity of the query is 51,661.

Since the maximum complexity allowed for queries is 50,000, the error you’ll see with this query looks like this:

{
  "errors": [
    {
      "locations": [
        {
          "column": 3,
          "line": 3
        }
      ],
      "message": "Field icons is too complex: complexity is 51,660 and maximum is 50,000"
    },
    {
      "locations": [
        {
          "column": 2,
          "line": 2
        }
      ],
      "message": "Field release is too complex: complexity is 51661 and maximum is 50,000"
    },
    {
      "locations": [
        {
          "column": 1,
          "line": 1
        }
      ],
      "message": "Operation is too complex: complexity is 51661 and maximum is 50,000"
    }
  ]
}

In this case, simply removing one of the familyStyles in the filter on the svgs field would make it significantly less complex.

Counting Icon IDs vs. Counting Icons

To select the icons field is to select all icon IDs in a particular release of Font Awesome. Each item of icons has an id field that is a unique name within the icon set for a given version of Font Awesome.

For example, there’s an icon named avocado that, as of Font Awesome 6.4.2 is available in 8 different familyStyles. So that counts as eight icons, but only one icon ID.

There are some properties about that icon ID that are the same regardless of familyStyle. See the various fields on the Icon object. It’s unicode, or label, for example.

So the complexity multiplier that corresponds to the icons field is the count of icon IDs in a release, not the total number of icons.

For example, in Font Awesome 6.4.2, there are:

3,690 icon IDs
24,208 icons

The following query gives you both counts for the release:

query {
  release(version:"6.4.2") {
    iconCount{ pro }
    iconIdCount{ pro }
  }
}

There are 24,208 icons because most of the icon IDs are available in the same 8 familyStyles as avocado. So why isn’t it just 3,690 icon IDs multiplied by 8 familyStyles for total of 29,520? Why are there 24,208 icons instead of 29,520? Because some of the icon IDs are only present in the Classic Brands familyStyle.

There are 473 icon IDs that are in the brands familyStyle, and most of those are available only in that familyStyle. But making the math even more complicated, there are just a couple of those are both in Classic Brands and the other 8 familyStyles.

So it just works out that there are 24,208 distinct icons in Font Awesome 6.4.2.

Playing it Safe

If your query selects SVGs for all icons in some release, then a safe bet is to use the filter on the svgs field to select just one familyStyle at a time. If your application requires three different familyStyles, then issue three separate queries, each selecting one of those familyStyles.

For example, the following query has a complexity of only 22,141, and it gives you everything you need to render all SVG icons in one familyStyle for Font Awesome 6.4.2:

query {
  release(version:"6.4.2") {
    icons {
      id
      svgs(filter:{familyStyles:[
        {family: SHARP, style: LIGHT},
      ]}) {
        familyStyle { prefix }
        width
        height
        pathData
      }
    }
  }
}

You can get a decent estimate of the complexity using the iconIdCount { pro } value in the query above as the multiplier for the icons field (3,690) and multiplying that by the number of fields selected under icons, which is 6. That’s 22,140. Add 1 for the top-level release field, and you’ve got the total of 22,141.

If you change the filter to use any other single familyStyle, it’ll have the same complexity.

So you could run that same query three times for three different familyStyles, if that’s what your app needs, and be confident that the complexity will be well under the limit.

This same query would still be under the limit, even if run for a later release of Font Awesome where the iconIdCount doubles.

Constant vs. Variable Complexity

Complexity calculations for any given version of Font Awesome are stable. Font Awesome 6.4.2 has 3,690 icon IDs and 9 familyStyles. That won’t change. So a query whose complexity is based on those multipliers won’t change.

However, later releases will have more icon IDs and more familyStyles.

A query run against a smaller release may fit within the complexity allowance; but that same query when run against a larger release may be too big.

However, it’s also possible to use version="6.x", and that changes with each release.

As mentioned above, while Font Awesome 6.4.2 has 3,690 icon IDs, a future version will have more.

When you use version="6.x" in a query, you’re asking for whatever version is the latest major version 6 at the moment the query is executed. While the example query above had a multiplier of 3,690 on the icons field, if a later version of Font Awesome has 4,000 icon IDs, then that same field in the same query would have a multiplier of 4,000.