Slow API response with MirrorValue

Hi, as a developer of Monday.com integrations, we are experiencing significant performance issues in using the 2023-10 API with specific regards to Mirror item display values.

Below is an example of a typical query we might run within our integrations, which is followed by the next_items_page query to fetch the remaining items.

query getItems($columnIds: [String!]) {
boards(ids: []) {
items_page(limit: 100) {
cursor
items {
id
name
column_values(ids: $columnIds) {
id
type
text
value
… on MirrorValue {
display_value
}
}
group {
id
title
color
}
}
}
}
}

The info below shows the response times we are getting from the Monday.com 2023-10 API based on the number of mirror columns present in the query.

15 native columns, 0 mirror columns - 5 seconds
15 native columns, 1 mirror column - 15 seconds
15 native columns, 2 mirror columns - 25 seconds
15 native columns, 3 mirror column - 30 seconds
15 native columns, 4 mirror columns - 42 seconds
15 native columns, 5 mirror columns - 48 seconds

These response times are quite unacceptable by our customer base.

When comparing the previous response times from the 2023-07 API we could run the following query with 15 native columns, 5 mirror columns present and receive the full result in 7 seconds.

query getItems($columnIds: [String!]) {
boards(ids: []) {
items(limit: 100) {
id
name
column_values(ids: $columnIds) {
id
type
text
value
}
group {
id
title
color
}
}
}
}

We are urgently seeking some clarification or indication as to how we can improve our API response times with queries of this nature that involve mirror items, as with the current approach, if we were to try and collect 500 items, we could be sitting waiting for minutes to get data back (assuming the Monday.com API doesnt timeout)

3 Likes

How many items are involved in these tests? I’m assuming more than just one.

1 Like

We are running tests with boards containing between 500 to 7000 items, limiting each request to 100 items, and getting similar response times across this range.

Thanks. Just wanted to know so everyone had a sense of the scale of it - particularly the R&D team.

Hello there,

Our team is investigating this. I will let you know as soon as I have an update :grin:

Cheers,
Matias

1 Like

We’re experiencing the same or a very similar issue. The following query, for a board with 20 mirror columns and only 60 items

query getBoardTasks ($board_id: ID!) {
  boards (ids: [$board_id]) {
    id
    items_count
    items_page  {
      items {
        id
        column_values {
          id
          type
          column {
            title
          }
          __typename
          ... on MirrorValue {
            id
            display_value
          }
        }
      }
    }
  }
}

returns an error

{
    "error_message": "Internal server error",
    "status_code": 500
}

If I comment out the display_value property then the request succeeds. The response speed is not so much of an issue for us, but errors block our customer from accessing their data. @Matias.Monday I can share more details if needed.

Hello there @TuomasTammi,

I will check if it is related and let you know!

Cheers,
Matias

1 Like

Hello @TuomasTammi,

It looks like this is probably related. Our team is working on this.

I will let you know when I have an update :grin:

Cheers,
Matias

1 Like

Hello everyone!

A change was deployed and it looks like there is a significant improvement.

Would you be able to test this again and tell me how it goes for you?

Looking forward to hearing from you!

Cheers,
Matias

Unfortunately we’re not seeing any change. The same request (above) still fails with the same error.

Hi @Matias.Monday, also confirming on our end we are seeing no improvement. Have tested all previous queries and are seeing the same response times as before. Can you please confirm if changes were applied to the 2023-10 API and whether this is available in USA and AUS regions?

Hello everyone! I will check this again with the team and update you!

1 Like

I’m getting daily calls from customers complaining of the slow loading speed of our apps due to the query speed.

Did you get an update from your team @Matias.Monday ?

I just need to know if I should be waiting for an improvement or if I need to re-think the entire structure of my customers accounts to remove mirror columns.

I am somewhat relieved to have discovered this thread. I thought I was doing something wrong. I have resorted to querying only one item at a time as to avoid a timeout error. I then use the cursor object to paginate through all items. It takes forever though. I imagine that calling display_value is some recursive procedure that traverses from one source to another until it finds the original. It would be great if display_value could be fixed. I just assumed it to be complex and time was the price to pay for it.

Just to confirm, the 2023-07 API does not seem to suffer from the slowness. Furthermore, it seems as if one can get text from Mirrored fields by just calling text. This would give a null value in the new API. The new API (2023-10) seems overly complex. I also don’t know why the new API requires one to go the extra mile in extracting the values for a Mirrored Field.

I do not have inside knowledge of the monday.com GraphQL resolver, I’m only speaking based on observation and reports publicly. All assertions here are my own speculation though presented as absolutes so I don’t have to say appears 50 times.

It appears the problem is death by a thousand fetches in the resolver. The current resolver is iterating items, and then the items columns, and fetching for each column. Thats the only way that explains the growth by mirror count * item count.

I suspect a tenacious programmer could devise a better resolver that iterates many items and columns, and builds a large list to fetch, and then caches the results because it is not uncommon for a board of many items to link to the same small set of items (such as orders to customers, clients to sales reps, or employers to states).

An ambitious one could probably figure out how to asynchronously do this in some fashion.

Knowing what you can get from the API about mirror columns, everything is there to implement a more efficient proxy resolver locally. This seems like, if monday can’t promise a solution in a reasonable timeframe, a potential albeit costly and painful workaround.

1 Like

Hello everyone! Our team is working on this.

I will let you know when I have an update :grin:

Cheers,
Matias

1 Like

Can you give an ETA for the fix?

We’ve had to disable mirror columns for many users. They are, quite understandably, asking us when they will be able to see their mirror column data again.

Hello everyone,

Our team has informed me that a fix was deployed today and it should improve this.

Can you pelase check how it does now and let me know?

Cheers,
Matias

2 Likes

Thank you @Matias.Monday! and your team :smiley:

So much better, running 10+ mirror columns and getting 8-10 second response times now.

My customers have also noticed a big difference with the loading times in our apps already.

2 Likes

Yes, also thanks @Matias.Monday - all is looking much better on my end too. Have tested queries with a range of 1-10 mirror columns, batches of 100, all appear to be resolving in an average of 5 seconds now :+1:

2 Likes