This is looking great, @Polarpi. I'm wondering if we can refactor these two below methods a bit to get it in bit of a more functional programming style, which can make this complex logic a bit easier to debug if things aren't working as we expect. Right now we're doing the spidering computations to the array in-place, which results in there being side effects produced in the computation—for example, the resourceList passed in as an argument to spiderResources will now be modified after calling the function rather than returning a new, modified list, since JS is passing the reference to the array in for resourceList and we're modifying that reference.

It would be great if we can refactor a bit of the logic here to have us map over the resourceList, and for each resource, calling computeSpideredCoordinates which takes in resource, the (unmodified) resourceList, and returns a copy of resource with the spiderCoordinates added. Here's an example of how that's handled in the backend with distances. We don't need RamdaJS necessarily here, but if we can make the computeSpideredCoordinates be solely responsible for managing adding the coordinates to one resource object and returning a copy with those values added, then it becomes a matter of us mapping through resourceList to do this for each resource object.

I definitely see the challenge in having computeSpideredCoordinates do it this way rather than filtering and modifying them all simultaneously. Definitely open to alternate solutions here, this is just a suggestion—I think the main priority is to make sure that we're not causing unintended side effects by calling spiderResources to the passed in array or underlying objects, which is why immutability is key here.