You requested a relationship graph up to a degree of separation of 50! That almost qualifies as a DoS attack 
Haha it was just to illustrate it. For example, even at 100 it doesn’t break on the owner account.
A more reasonable value is like 10. But even at that, the guest account fails. In fact, even at something like 3 or 4, which is just a couple above the default, it fails (edit: I should say, one time it took ridiculously long which is as good as a fail).
BTW, regarding the default value and requests - and excuse my ignorance - wouldn’t it make sense to cache the tree layout such that it only needs 1 request and client-side just renders it? i.e. it seems when you set the max degree of separation or even just click on a type of graph, it is re-calculating everything, all the connections, is that right? But for the most part, changes in relations would only happen with changes to the tree and that too in existing relations. So I’m thinking that the layout be cached and there be a manual re-calculation when actually needed (after adding or editing relations). So for instance, when a tree is uploaded, it’s already calculated everything and the whole tree is saved in some instructions such that all you’re really doing is pulling it rather than calculating each person. I only say this because when you said “loading the data for large degree of separation can be very time/resource consuming” I can only think that it’s calculating things everytime. Like imagine a sorting algorithm that has sorted everything and you request only a part of the results - instead of just showing the half, it’s sorting once again (I understand there’s a nuance with a sorting alg but let’s ignore that in this case and say we want full sort but just displaying part of it). Once again pardon any ignorance as I have no idea about the backend here 
