MirrorValue drastically increasing response times

monday Apps & Developers
, ,
1

I’ve got a query that I am running, in which there are a large amount of Mirror columns. Previously, I was able to fetch all of this data using the text field. However, introducing unravelling MirrorValue increases the time of this request from 2 seconds to 7.5 seconds while still only querying a single column. It looks like this continues to compound with more data and columns.
The data stored in the MirrorValue is required to resolve the value of the column.

Am I doing this completely wrong? This seems like a massive regression with the new API. In addition, since the pagination requires a cursor from the previous response, this drastically increases the net time to paginate through a board as concurrent queries are not possible.

In addition, it doesn’t look like I can actually grab the text values of Dropdowns at all with this new system.

Old Query (2 seconds):

"{boards(ids:[BOARD_ID]){items (limit: 50, page: 1) {name, group(){title} column_values(ids: [mirror1, dropdown, shift_days1, shift0, sample_column, mirror42, mirror82, mirror3, check4, data_catalog_id]) {id, title, text}}}}"

New Query, Single Column, No MirrorValue (2 seconds):

"{boards(ids:[BOARD_ID]){items_page (limit: 50) {cursor items { name column_values ( ids: [\"mirror1\"]){column {id} id type value }}}}}"

New Query, Single Column, Expand MirrorValue (11 seconds):

"{boards(ids:[BOARD_ID]){items_page (limit: 50) {cursor items { name column_values ( ids: [\"mirror1\"]){column {id} id type value ...on MirrorValue{ text: display_value} }}}}}"

New Query, All Columns, No MirrorValue (2 seconds):

"{boards(ids:BOARD_ID){items_page (limit: 50) {cursor items { name group {title} column_values ( ids: [\"mirror1\",\"dropdown\",\"shift_days1\",\"shift0\",\"sample_column\",\"mirror42\",\"mirror82\",\"mirror3\",\"check4\",\"data_catalog_id\"]){column {id} id type value }}}}}"

New Query, All Columns, Expand MirrorValue (40 seconds):

"{boards(ids:[BOARD_ID]){items_page (limit: 50) {cursor items { name group {title} column_values ( ids: [\"mirror1\",\"dropdown\",\"shift_days1\",\"shift0\",\"sample_column\",\"mirror42\",\"mirror82\",\"mirror3\",\"check4\",\"data_catalog_id\"]){column {id} id type value ...on MirrorValue{ display_value} }}}}}"
2

This is a known issue with the display_value of mirror columns and they are actively working on a fix.

Just an FYI previously with dropdowns the value also only provided the index. You could get text values within the text field of the column value and this still works. You could never get them in a structured value in the old API (you could match them up with an index via the settings_str of the column though). With the new API for dropdowns you can do something like this and actually return the selected dropdown values with the id and label.

{
  items(ids: "123342342"){
    column_values(ids: "dropdown"){
      id
      type
      text
      value
      ... on DropdownValue {
        values {
          id
          label
        }
      }
    }
  }
}

One method of speeding up pagination in the new API is to return just items and their IDs (and maybe names), avoiding column values which require additional lookups by the GraphQL resolvers. You can get up to 500 at a time this way relatively quickly.

Then you can parallelize requesting the full data with simple items(ids: [ids]) queries, which you can do batches of 100 and execute 5 at a time. Simultaneously, you can be fetching the next batch of IDs.

Not the ideal solution, but it should speed things up. That said, for your main performance issue, wait and test periodically over the next week or two and you may find they’ve solved it hopefully.

1 Like
3

Awesome, thanks for the fast response. I missed the DropdownValue, thanks for the details there.

I’ll wait for the MirrorValue performance to get better, good to know this is on the team’s radar.

1 Like