Query item by ID using items_page

hi @jonathan.van

The ids arguments needs to go to items_page (not items). Why don’t you just use items as your root query as you seem to know the itemId?

Could you give an example of what that query would look like?

@jonathan.van you can use ItemQuery to supply your ids. Here’s the documentation

An example of such query:

boards(ids: [BOARD_ID_1]) {
    id
    items_page(query_params: {ids: [ITEM_ID_1]}) {
      cursor
      items {
        id
      }
  }
} 

Ok great, that example really helps, thanks!

or just items as the root query (you don’t need the boarId)

items(ids:5820698515) {
id
name
column_values(ids: “person”) {
value
text
}
}

This is the simplest form 😀

@basdebruin documentation recommends to use items query at root when you don’t know the boardId. It strongly recommends to use items_page instead 😉

Just look how many warnings on this page: Items

That is a common misunderstanding, see also Please help - can't get column_values? - #8 by codyfrisch

@basdebruin thank you for sharing the link 🙏. Actually, I am not referring to query speed, just what documentation is recommending.

Totally agree with you, root items was waaaayyy much faster then the actual items_page. Since we migrated to 2023-10 and start using items_page, we noticed a huge regression in our performances that reach sometimes x3 slow requests than previous version.

With @samicaracand we were struggling for days figuring out what was causing these performances issues. Even the 500 limits with items_page is not respected when you provide 500 item ids! see this: [2024-01 API:] items_page query limits - 500 or 100?

The best approach differs case by case. You @Adnene are talking about limits (500 or 100) but the original ask from @jonathan.van was for just one item. For one item (knowing the itemId) I would always use the items root query.

@Adnene I’ve even recommended for some situations to use the items_page to only return the item IDs. no values, not even the name. When using items_page this way its much faster since its not invoking the column_value or any other resolvers (say group, subitems, updates, etc.)

Then once you have IDs, fetch the IDs using the items root query in batches of 100. Even in JS by not using await on query, you can loop through batches of 100 really quick, then await Promise.all(promises) and handle the results from the 5 queries you sent out.

With the way JS works each of those query functions would reach the internal await on the actual HTTP request, and JS moves onto making the next request while it awaits the actual network activity. This lets you execute the slow part (the monday.com getting the data) in near parallel without JS being multi-threaded!

Now when you do the await Promise.all(promises) you will get an array of results from the queries you can process. You’d also get setup with the right loop and structure for the pagination so that you’re also getting the next pages of IDs at the same time so you can create the next batch to fire off as soon as you’re ready, maybe even create a queue of batches.

But now I’m getting into software architecture and its too much for this venue! But I hope the concept inspired you. In fact you may see this be faster than the pre-items_page methods you used.