Improve nested docs performance #8302
Replies: 1 comment 2 replies
-
The reality of the situation with anything nested to the point of causing performance issues is that hooks are not the right use-case for it. There is simply not much that can be done. Consider the case, like in your example, when deeply nested children have to be updated. Now consider if those children have other hooks that need to be run after this update. We are talking about exploding complexity here. The real solution to deeply nested updates is to offload the computation to another server/service as a task using something like a scheduler and use sockets to update your users ui if you need to. You queue up your changes, let the the task run in a secondary server outside of your production payload server, and then emit the necessary data to update your users UI if necessary. I don't think queues, tasks, scheduling, and sockets are really in-scope for Payload tbh. |
Beta Was this translation helpful? Give feedback.
-
Hey!
The nested docs plugin currently saved the breadcrumb in the database whenever the document is saved. This is fine and I guess it improves read performance and makes the breadcrumbs queryable which is great.
The problem arises when you change a parent node. Since that requires all children to possibly need new breadcrumbs and if you have a site with hundreds of pages (or more) the documents that are high up in the tree will have really long save times. This becomes an even larger issue when using a managed database which often has slightly higher latency than a local one.
I'd be interested to see if there are any solutions for this. For example would it be possible to
Beta Was this translation helpful? Give feedback.
All reactions