API changes to make it scalable and useful for multiple children

The new API addition is fantastic! However it needs couple of important changes to be useful otherwise it results in too many extra API calls, which I think is not great for rate limiting and server load.

The problem is that there is no way to no know if a node has any children and if they were modified.

So currently if we want to print all content from a node, we must call the API for each single child node to check if it returns further nodes and so on. This is quite API intensive.

A simple change will make this a LOT more scalable. The node object needs two additional fields:

  • num_children: So if this is zero, we need not make another API call to check that. We call the API again only if this is > 0.
  • children_last_modified: This shows the modified time of the whole “tree”. So if any child or sub-child is modified, it should reflect that. This allows the client to update its cache if needed. For large nodes, I think this is absolutely essential as crawling the whole tree every single time is not feasible. If there is no visibility into the modification time of the children, there is no choice but to crawl the node every single time.

API call to get the whole node and its children

Along with this, it would be a huge improvement to get an API call type that returns the whole node tree, not just the node. This would reduce API call load by 10-100x depending on the tree complexity.

4 Likes