Hi!
Recently we ran into issues with the default max json depth of 64 in the delivery API. It turned out to be caused by having multiple block lists nested which caused the in-memory obejct depth to exceed 64, because of the transparent wrapper objects the Delivery api uses to model the response before flattening it a bit to return the final result. The actual result only had about 33 levels of nested json, which is still a lot, but acceptable given the structure of the page we were retrieving. In the end I upped the JsonOptions.MaxDepth to 128, which caused my failing queries to work again, but it didn’t feel as if that solution is really future-proof.
While debugging I discovered that JsonOptions.IgnoreCycles does not work for the Delivery API because nodes that are visited twice will create a new object even for objects it has already seen. I think this could be improved by adding some sort of a ApiResponseBuildContext which tracks visited nodes and caches them to not only improve perfomance by not having to serialize the same node twice, but also enable setting cyclic references to null (or some other default value such as a non-expanded version of the node), this would hopefully decrease the in-memory object depth significantly in the case of cyclic references combined with a property expansion of 3 of more levels.
This would also prevent having a sort of “related pages” picker that will let content editors create cyclical references where we don’t really care about the back-reference anyways.
I am curious what the more experienced umbraco devs’ thoughts are on this matter.